Re: Media Type for resource archives

We (Jive) use the multipart/form-data in lots of use cases, such as
uploading a document (with a well defined JSON format) plus some associated
attachments.  However, we don't enforce a requirement that the JSON data be
the first body part -- instead, we search through the available body parts
for it with some well-defined heuristics, and treat all the other body
parts as attachments.

Craig McClanahan


On Fri, Jan 10, 2014 at 2:35 PM, Jan Algermissen <[email protected]
> wrote:

>
>
> Hi,
>
> I am thinking about a media type for bundling together a bunch of
> resources[1] into a single file. With these files I want to store a
> manifest file.
>
> One option would be to just use a zip-based format and an manifest file
> with a well known name.
>
> The problem with this is that useful stream processing of such a file can
> only be done by ensuring that the manifest is the first entry when
> unzipping. Apparently it requires some stunts to control the ordering of
> the zip entries and who knows whether the other end uses a compatible
> implementation.
>
> Solution would be to unpack to disk first and go from there. Not nice.
>
> A possible alternative would be to use a multipart format where I can
> simply require the manifest to be the first part. Then just zip that file
> or rely on transfer encoding to reduce the bytes on the wire.
>
> Nice things about that:
> - Ordering is guaranteed
> - Full support for per-part MIME headers
> - Content-Length enables fast splitting of the parts
> - cid: URIs make for natural, standard URI-references inside the file
> - stream processing without temporary storage
>
> I am interested in reactions to the two alternatives or any ideas beyond
> that.
>
> Jan
>
> [1] Well, obviously their entities at some point in time
>  
>