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

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

Expand Messages
  • Jonathan Ballard
    Jan 11, 2014
      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:


      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.


      [1] Well, obviously their entities at some point in time

    • Show all 7 messages in this topic