Support mime/alternative

[GoogleCodeExporter]

I've been investigating how best to transactionally load multiple
representations of a document and it seems multipart/alternative [1] fits
the bill nicely.

One issue to consider is whether this should delete any alternative
representations already stored that aren't included in the payload (I would
argue no, but if the idea is to be able to fully replace an object, it
would be neat to be able to specify a way to delete other representations
in one shot.)

Another is according to the RFC the ordering should be from least to most
descriptive, but supporting a q on the inbound content types should render
this irrelevant.

If this is already supported, please disregard -- I couldn't get RESTTest
working with it, but I couldn't get multipart/form-data working either
(stream unexpectedly ended) even with headers and body I know were correct.
I figured it was worth filing a ticket regardless.

This may also be something that's doable with jsgi middleware but if the
core accepted a content-type that could fully alter the object tree,
including alternative reps, it would allow middleware to do more with a
request by simply altering the env rather than handling any commits itself
(which seems like the *right way*).

[1] http://tools.ietf.org/html/rfc2046#section-5.1.4

Original issue reported on code.google.com by dean%dea...@gtempaccount.com on 6 Aug 2009 at 9:37

[GoogleCodeExporter]

Thinking about this more, I'm pretty sure this is another something jsgi 
middleware
would be better suited for. But _how_ is still a bit of a mystery to me. Say 
three
representations come in a multipart POST. A clean middleware pattern to support 
this
would be to clone the env and add the first representation to jsgi.input, update
env['CONTENT_TYPE'], and add a Transaction: open header. Upon success, take the
response's location and do the remaining representations as PUTs to the 
response's
Location, closing the transaction on the last one. I'm not sure if jsgi supports
multiple app(env) calls (wsgi has the start_response callable which precludes 
this,
but jsgi and jack seem designed to accomodate this). If it does, what needs to 
be
taken into consideration? Persevere seems to have issues with the streams for 
now. If
this isn't the right approach, would setting up a new mock request be better? 
Or a
whole new XHR?

Original comment by dean%dea...@gtempaccount.com on 9 Aug 2009 at 4:01