Hi Jerome,
thx for your response and the implementation suggestions
Jerome Louvel wrote:
[...] we could make a Representation based similar composite that
- holds a list of embedded Representations (of which some are
referring to files on disk, and some just hold parameter-values)
- all to be serialized out with correct boundary/mime multipart layout
Yes, we miss support for multipart on the client-side and that would be a
good opportunity to remove the need for a third-party extension (FileUpload)
on the server-side, reusing the Representation paradigm as well.
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?
- I also think the fileupload dependency is there for (mainly)
server-side parsing of the multipart format, no?
Given the asymmetric nature of the parsing/generation
involved with this I'm not convinced the same class
should be responsible for the parsing on server side
(as was suggested in the RFE).
I think this is feasible, at least let's try :-)
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)
My first impression is that based on the commons-fileupload a
helper or convertor class could easily be converting the
input-representation into a multipart-representation that
is again referring to (temporary) files on disk (created by
fileupload)
I'm not sure I like the temporary files approach that much. It should be
possible to process each part on the fly, leaving the liberty to the end
user to write the part representation to disk or anywhere else.
yep, my idea exactly, consider the temp-file notation as a slip of the
tongue there
Things I'm unsure of:
- Relation to and expectations on "Form" (haven't used that really,
pointers/docs/samples welcome)
Form is an in memory structure that can be read/written from/to a
Representation:
http://www.restlet.org/documentation/1.1/api/org/restlet/data/Form.html
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?
regards,
-marc=
