- From: Thaddee Tyl <thaddee.tyl@gmail.com>
- Date: Wed, 28 Aug 2013 14:29:20 +0000
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Jake Archibald <jakearchibald@google.com>, Yehuda Katz <wycats@gmail.com>, Sam Tobin-Hochstadt <samth@ccs.neu.edu>, Jonas Sicking <jonas@sicking.cc>, WHATWG <whatwg@whatwg.org>, Alex Russell <slightlyoff@google.com>, Andrea Marchesini <baku@mozilla.com>, Jason Orendorff <jorendorff@mozilla.com>, David Herman <dherman@mozilla.com>
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@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.
Received on Wednesday, 28 August 2013 16:57:21 UTC