A couple of us have been toying around with the idea of making zip
archives first-class citizens on the web. What we want to support:
* Group a bunch of JavaScript files together in a single resource and
refer to them individually for upcoming JavaScript modules.
* Package a bunch of related
On 8/28/13 9:32 AM, Anne van Kesteren 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
On 8/28/13 9:32 AM, Anne van Kesteren wrote:
I'm not sure we need to consider sub-scheme if zip-path can work as
it's more complex and not very well thought out. E.g. imagine
view-source:zip:http://www.example.org/zip!test.html.
What's the issue with that? Gecko supports that (with jar:, not
On Wed, Aug 28, 2013 at 4:04 PM, Boris Zbarsky bzbar...@mit.edu wrote:
What's the issue with that? Gecko supports that (with jar:, not zip:),
fwiw.
As far as the web platform is considered today, URL objects are just
that. In Gecko you either have a URL object, or a linked list of URL
objects.
Two implementation risks to keep in mind:
1) Both jar: and mhtml: (which work or worked in a very similar way)
have caused problems in absence of strict Content-Type matching. In
essence, it is relatively easy for something like a valid
user-supplied text document or an image to be also a valid
Resending. I recommend that people replying trim the address list as
apparently Too many recipients to the message is a thing for this
mailing list.
On Wed, Aug 28, 2013 at 4:54 PM, Eric Uhrhane er...@chromium.org wrote:
Without commenting on the other parts of the proposal, let me just
mention
On Wed, Aug 28, 2013 at 8:04 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/28/13 9:32 AM, Anne van Kesteren wrote:
I'm not sure we need to consider sub-scheme if zip-path can work as
it's more complex and not very well thought out. E.g. imagine
On 8/28/13 11:40 AM, Anne van Kesteren wrote:
On Wed, Aug 28, 2013 at 4:04 PM, Boris Zbarsky bzbar...@mit.edu wrote:
What's the issue with that? Gecko supports that (with jar:, not zip:),
fwiw.
As far as the web platform is considered today, URL objects are just
that. In Gecko you either
On Wed, Aug 28, 2013 at 4:54 PM, Eric Uhrhane er...@chromium.org wrote:
Without commenting on the other parts of the proposal, let me just
mention that every time .zip support comes up, we notice that it's not
a great web archive format because it's not streamable. That is, you
can't
On 8/28/13 12:20 PM, Jonas Sicking wrote:
* It makes it impossible to have create a relative URL from inside the
zip file to refer to something on the same server but outside of the
zip file.
I think this comes back to use cases.
If the idea of having the zip is here is stuff that should live
On Aug 28, 2013, at 6:32 AM, Anne van Kesteren ann...@annevk.nl wrote:
A couple of us have been toying around with the idea of making zip
archives first-class citizens on the web.
This sounds like a great opening for a discussion about the pros and cons of
doing such a thing. But until such
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 ann...@annevk.nl wrote:
We have thought of three approaches for zip URL design thus far:
* Using a sub-scheme (zip) with a zip-path
Again from the right address...
On Wed, Aug 28, 2013 at 8:47 AM, Eric U er...@google.com wrote:
Without commenting on the other parts of the proposal, let me just
mention that every time .zip support comes up, we notice that it's not
a great web archive format because it's not streamable.
On Wed, Aug 28, 2013 at 8:47 AM, Eric U er...@google.com wrote:
Without commenting on the other parts of the proposal, let me just
mention that every time .zip support comes up, we notice that it's not
a great web archive format because it's not streamable. That is, you
can't actually use
On Wed, Aug 28, 2013 at 12:07 PM, Eric Uhrhane er...@chromium.org wrote:
We've covered this several times. The directory records in a zip can
be superseded by further directories later in the archive, so you
can't trust that you've got the right directory until you're done
downloading.
On Wed, Aug 28, 2013 at 10:21 AM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Aug 28, 2013 at 12:07 PM, Eric Uhrhane er...@chromium.org wrote:
We've covered this several times. The directory records in a zip can
be superseded by further directories later in the archive, so you
can't trust
On Fri, Jul 12, 2013 at 1:32 PM, Ian Hickson i...@hixie.ch wrote:
You are welcome to register these on the wiki and convince people to use
them, sure. Seems like they already have solutions, though, as you show:
Would you kindly link me to the wiki?
Sounds like this is already solved,
On Fri, 23 Aug 2013, Glenn Adams wrote:
On Fri, Aug 23, 2013 at 4:16 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 23 Aug 2013, Glenn Adams wrote:
As has been pointed out a number of times, there are already
implementations and JS client code using this technique.
Where?
I think
Since Gecko has already implemented this behavior, I've gone ahead and changed
WebKit's behavior:
http://trac.webkit.org/changeset/154761
- R. Niwa
On Aug 26, 2013, at 7:09 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/26/13 9:51 PM, Ryosuke Niwa wrote:
That's good to hear. So we're
Hey Anne,
On 28/08/2013, at 11:32 PM, Anne van Kesteren ann...@annevk.nl wrote:
* Fragments: fail to work well for URLs relative to a zip archive.
Fragments are conceptually the cleanest as the only part of a URL
that's supposed to depend on the Content-Type is the fragment.
However, if
On Jul 13, 2013, at 5:55 AM, Andy Davies dajdav...@gmail.com wrote:
On 12 July 2013 01:25, Bruno Racineux br...@hexanet.net wrote:
On browser preloading:
There seems to an inherent conflict between 'indiscriminate' Pre-parsers/
PreloadScanner and responsive design for mobile. Responsive
Hi Ryosuke,
Based on the feedback here, it doesn't sound like you are a huge fan
of the original proposal in this thread.
At this point, has any implementation come out in support of the
proposal in this thread as a preferred solution over
noexecute/execute()?
The strongest support I've seen in
22 matches
Mail list logo
