Hi Marc, > [...] 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. > 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 :-) > 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. > 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. > - Where and how parsing on the upload should be plugged into > the current design. See the attached files for skeletons of potential MultiPartRepresentation and PartRepresentation classes. Best regards, Jerome
MultiPartRepresentation.java
Description: Binary data
PartRepresentation.java
Description: Binary data
