Loading ...
Sorry, an error occurred while loading the content.

19585Re: [rest-discuss] Media Type for resource archives

Expand Messages
  • Jonathan Ballard
    Jan 12, 2014
    • 0 Attachment
      Here is one link for experiments:

      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 <matthewlmcclure@...> wrote:

      Got a link describing QUIC in more detail? My Googling failed me.

      On Jan 11, 2014 4:57 PM, "Jonathan Ballard" <dzonatas@...> 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 <craigmcc@...> 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 <jan.algermissen@...> 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




    • Show all 7 messages in this topic