<br><br><div class="gmail_quote">On Tue, Feb 9, 2010 at 2:36 AM, Aristotle Pagaltzis <span dir="ltr"><<a href="mailto:pagaltzis@gmx.de">pagaltzis@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> 3) upload a document for the user and the document must include<br>
> an associated collection of meta data (e.g. filename,<br>
> timestamp, author etc.). The uploaded document must include<br>
> this meta data before it can be accepted.<br>
<br>
</div>That sounds like the case I was thinking about: just do a PUT<br>
request with X-MyApp-Filename, X-MyApp-Timestamp etc headers.<br></blockquote><div><br></div><div>Of course, I left out the ability to upload multiple flies at once. Doing that with headers could get ugly. (X-MyApp-Filename-01, X-MyApp-Filename-02, ...) Of course, could just not provide that multiple-file upload ability to API users and limit it to web users. That would work ok.</div>
<div><br></div><div>With XML-RPC we just have multiple <upload> struct elements that are containers for the meta data and the base64 file contents. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
(Another option, which is better in some ways I think, would be<br>
the two-request approach as above, though that would be more<br>
complicated. Ie. the client POSTs the metadata, the server files<br>
the data away temporarily and returns a link to which the client<br>
can PUT the file, and only once that request has succeeded does<br>
the server store both metadata and file in their proper place.)<br></blockquote><div><br></div><div>That's a bit of redesign of the application for a two-phase upload. Seems a shame to have to add new database tables and cron jobs to clean up incomplete uploads just because of my choice of serialization. I agree that's probably the cleanest design, though. From past experience I can assume some customers will have trouble adding request headers for the libraries they are using.</div>
<div><br></div><div>form-data is possible serialization, but it's a flat serialization so also need to have fields like filename_01, title_01, filename_02, title_02 to handle multiple uploads at once. (Plus, the app already handles that form-data). I'm not sure how much meta data can be associated with an upload in form-data (other than filename, content-disposition, and content-type), or if the libraries clients use to create a request can be that creative.</div>
<div><br></div><div>XML-RPC is ugly but nicely handles multiple uploads with associated meta data for each, and can be stream parsed so that the base64 file data is chunked to a temp file and not stored in memory.</div><div>
<br></div><div>JSON provides the nice nested structures but, IIUC, has to be in-memory to parse. I hate those "out of memory!" messages, so it would be very nice to not have the file uploads in JSON.</div><div>
<br></div><div>Not pretty at all, but maybe using form-data with a JSON-encoded "meta" field that has a list of uploads with associated meta-data including a field_name with each upload that associates it with a field that contained the uploaded file. Most client libraries have a way to send form-data, so that would be easy for customers to implement.</div>
<div><br></div><div>None of those are great options.</div><div><br></div><div><br></div></div>-- <br>Bill Moseley<br><a href="mailto:moseley@hank.org">moseley@hank.org</a><br>