Hi Marc, > thx for your response and the implementation suggestions
You're welcome! > this causes some confusion on my end: > > - I don't see how dependency on a third-party thing is a bad > thing, what am I missing? It is not a bad thing in itself even if it always adds complexity. The support for multipart representations is an important feature for Restlet users. I think we should support it in the core, out-of-the box, using consistent API paradigms (Representation subclass). I would also like to support the uniform client-side/server-side capability that the rest of the API provides. Relying on a third-party library in this case requires more set-up (not a big deal for experienced developers) and requires to learn a new API (maybe two if you want to post multipart representations and accept them at the same time). > - I also think the fileupload dependency is there for (mainly) > server-side parsing of the multipart format, no? Right. > Well, there is other considerations as well: > > in my mind multipart-mime-encoding is only one way to communicate > 'composite' representations > > another clear use case I see is supporting 'archived' (zip, tar, tgz, > ...) representations: Thinking about a restlet app that can return > zipped up directories and such > > In both cases I see a composite model that holds different parts, > although they have a different serialization format on the wire (and > different mime-type) Very good point. There is probably place for a more generic API, maybe based on CompositeRepresentation & PartRepresentation base classes. > yep, my idea exactly, consider the temp-file notation as a > slip of the tongue there Perfect > > I indeed don't think it is appropriate for MultiPart forms > > which can contain very large 'parameters' like whole files. > > So this sounds like a separate in memory structure that can > hold these composite-like structures then? That is right and only applicable for small structures. Best regards, Jerome
