Re: Media Type for resource archives

Here is one link for experiments:
 http://blog.chromium.org/2013/06/experimenting-with-quic.html

Since IPv6, we can use Content-Length to describe parts of the entire UDP
transfer. From that base, there are several ideas how to describe contents
of the parts, especially with Content-Type. QUIC adds connection
identifiers.

In my previous post here, even if there is no manifest, the connection
identifier could cause each <script> to source from the same single
transfer.

I used one similar implementation that batched 10,000+ separate requests
into packets that were only split by time instead of size. That was before
QUIC.

Notice the trade-off to wrap up <script>s without jQuery overhead (or JS
loaders).


On Sat, Jan 11, 2014 at 2:02 PM, Matt McClure <[email protected]>wrote:

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