W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] Zip archives as first-class citizens

From: Thaddee Tyl <thaddee.tyl@gmail.com>
Date: Wed, 28 Aug 2013 14:29:20 +0000
Message-ID: <CAE3TfZON8CsaNSaEQNaX7ghsjDeXbmOSxP8Oq3vLYXdxKJwDjg@mail.gmail.com>
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,


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?


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.


(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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:07 UTC