[whatwg] Zip archives as first-class citizens
Thaddee Tyl
thaddee.tyl at gmail.com
Wed Aug 28 07:29:20 PDT 2013
The idea of making zip content (and hopefully XZ content) available
feels right, but adding complexity doesn't.
On Wed, Aug 28, 2013 at 1:32 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
> We have thought of three approaches for zip URL design thus far:
>
> * Using a sub-scheme (zip) with a zip-path (after !):
> zip:http://www.example.org/zip!image.gif
> * Introducing a zip-path (after %!): http://www.example.org/zip%!image.gif
> * Using media fragments: http://www.example.org/zip#path=image.gif
W.r.t. the sub-scheme, KDE kioslaves have something highly similar
(available for instance on their file explorers). The syntax is the following
zip: <absolute path to zip> / <path to content>
For instance,
zip:/home/tyl/vault.zip/js/simplex.js
Sure, a "real" directory can have a .zip extension, but spread across
all KDE users since kioslave's inception, more than 10 years ago, that
hasn't been raised as an issue (at least, I couldn't find one through
their bug tracker).
As a result, may I suggest this?
zip:http://www.example.org/js.zip/simplex.js
W.r.t. using fragments, which I agree is the cleanest approach,
can we change the URL parsing algorithm
to authorize reading any number of fragments?
It would require adding # to the simple encode set, which
can have consequences I didn't think of.
http://example.org/assets.zip#html/frame.html#editor
(Is there a reason we should have a path=, then?)
That would also take care of nested zips.
More information about the whatwg
mailing list