Re: Media Type for resource archives

Got a link describing QUIC in more detail? My Googling failed me.
On Jan 11, 2014 4:57 PM, "Jonathan Ballard" <[email protected]> wrote:

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