Re: jar protocol

>

> Can you hash out a little bit more how this would work? I'm assuming you
mean something like:
>
>   <img src='/bundle.zip/img/dahut.jpg'>
>
Meh, sorta - but I was missing some context on the mitigation strategies -
thanks for filling me in offline.

Still, same kinda idea, could you add an attribute that allowed for it to
specify that it is available in a bundle?  I'm not suggesting that this is
fully thought out, or even necessarily useful, just fleshing out the
original question in a potentially more understandable/acceptable way...

  <img src='/products/images/clock.jpg'
bundle="//products/images/bundle.zip">

That should be pretty much infinitely back-compatible, and require no
special mitigation at the server (including configuration wise which many
won't have access to) - just that they share the root concept and don't
clash, which I think is implied by the server solution too, right?  Old UAs
would ignore the unknown bundle attribute and request the src as per usual.
 New UAs could make sure that an archive was requested only once and serve
the file out of the archive.  Presumably you could just add support into
that attribute for some simple way to indicate a named link too...

Psuedo-ish code, bikeshed details, this is just to convey idea:

   <link rel="bundle" name="products" href="//products/images/bundle.zip">
<img src='/img/dahut.jpg' bundle="link:products">

I don't know if this is wise or useful, but one problem that I run into
frequently is that I see pages that mash together content where the author
doesn't get to control the head... This can make integration a little
harder than I think it should be. I'm not sure it matters, I suppose it
depends on:

a) where the link tag will be allowed to live

b) the effects created by including the same link href multiple times in
the same doc

This might be entirely sidetracking the main conversation, so I don't want
to lose that I really like where this is going so far sans any of my
questions/comments :)

Received on Friday, 10 May 2013 15:13:58 UTC