Re: Media Type for resource archives

Look at QUIC, and consider this format and sequence:

<script src=... type="application/json+quic" var="abc" index="123"/>
<script src=... type="application/json+quic" var="abc" index="456"/>
<script src=... type="application/json+quic" var="abc" index="789"/>

Let the browser recognize the same manifest (...), let the extra micro-data
wrap up the statement:

var abc[123] = ... ;

Slight modification to change "var"+"index" to "part" is another solution.
I hope something like this makes HTML6.



On Fri, Jan 10, 2014 at 5:59 PM, Craig McClanahan <[email protected]>wrote:

>
>
> 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
>>
>
>  
>