Re: ZIP archive API?

2013-05-06 Thread David Sheets
On Mon, May 6, 2013 at 7:42 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Mon, May 6, 2013 at 4:27 AM, Robin Berjon ro...@w3.org wrote:
 On 03/05/2013 21:05 , Florian Bösch wrote:

 It can be implemented by a JS library, but the three reasons to let the
 browser provide it are Convenience, speed and integration.

 Also, one of the reasons we compress things is because they're big.*
 Unpacking in JS is likely to mean unpacking to memory (unless the blobs are
 smarter than that), whereas the browser has access to strategies to mitigate
 this, e.g. using temporary files.

 There's nothing here that implementations can do that JS can't. Both
 can read arbitrary parts of a file into memory and decompress only
 that data. And both would have to load data into memory in order to
 decompress it.

 The only things that implementations can do that JS can't is:
 * Implement new protocols. I definitely agree that we should specify a
 jar: or archive: protocol, but that's orthogonal to whether we need an
 API.

Is ZIP a protocol or simply a media type?

Either way, browsers will need to implement operations on the archive
format to understand its use in URL attributes.

The question then becomes: if browsers have an implementation of the
format for reference purposes, why do web apps need to ship their own
implementations of the format for archive purposes?

If web apps want to use some other archive/compression format, of
course they will have to distribute an implementation.

Thanks,

David

 * Implement Blob backends. In our prototype implementation we were
 able to return a Blob which represented data that hadn't been
 compressed yet. When the data was read it was incrementally
 decompressed.

 But a JS implementation could incrementally decompress and write the
 data to disk using something like FileHandle or FileWriter. So the
 same capabilities are there.

 Another question to take into account here is whether this should only be
 about zip. One of the limitations of zip archives is that they aren't
 streamable. Without boiling the ocean, adding support for a streamable
 format (which I don't think needs be more complex than tar) would be a big
 plus.

 Indeed. This is IMO an argument for relying on libraries.
 Implementations are going to be a lot more conservative about adding
 new archive formats, since they have to be supported for eternity,
 than library authors will be.

 I'm still hoping to see some performance numbers from the people
 arguing that we should add this to the platform. Without that I see
 little hope of getting enough browser vendors behind this.

 / Jonas





Re: URL comparison

2013-04-27 Thread David Sheets
 environment, I propose the adoption
of {} as the self-match syntax (not yet allowed under RFC 6570 but
could easily be a constructor no-op) and {_} as the wildcard match
(though {comment} could be used for commentary or when porting
patterns from systems which *do* bind into environments):

{} =  = self
{_} = ./{_} = siblings or self (but not deeper; /foo/bar/ |
{_} = /foo/bar/{any single path segment})
{}/ = any descendant of this document (/foo/bar | {}/ =
/foo/bar/{anything} and /foo/bar/ | {}/ =
/foo/bar//{anything})
{_}/ = anything with a deeper same-prefix path as this document
(/foo/bar/ | {_}/ = /foo/bar/{anything})
{}/{_} = any nieces/nephews/children of this document (/foo/bar/ |
{}/{_} is /foo/bar/{any}/{other})
/{} = the resource with the identity of the first path segment
equivalent to this document
/{_} = any first-level resource
/{}/ = same first path segment (':local-link(1)')
/{_}/ = any resource at least 1 level deep
/~{_}/ = any resource with first path segment beginning with ~

All of these patterns ignore the fragment (it indicates a delegated
resource subordinate to the primary resource) and require the same
username/password. None of these patterns match URIs with query
strings (their semantics are totally dependent on the server).

If you wish to match URIs with query strings, the syntax is simple:

{?} = self with same query string (incl. none)
{?_} = self with any query string (incl. none)
{}/{?} = any descendant with same query string (incl. none)
{}/{?_} = any descendant with any query string (incl. none)

Perhaps you wish to style only certain same-document references:

#defn-{_} = any same-document reference to fragments beginning with defn-

I understand these semantics are not trivial to implement and I have
begun a prototype implementation in my URI library.

The benefit of reusing the syntax and semantics of relative URI
references and URI templates are manifest. Structural pattern matching
(or, in this case, relative URI reference predicates) is incredibly
powerful as I hope I have demonstrated. Additionally, this design
leverages knowledge and important design constraints found in these
other specifications and their users.

I have not yet devised algebraic solutions for query string
permutation or URI normalization.

Disjunction of patterns is possible through normal CSS selector disjunction.

A major barrier to widespread deployment of a system of this kind is
the WHATWG URL specification. By unnecessarily coupling parsing,
normalization, and relative reference resolution, implementations
conforming to only the WHATWG URL specification cannot offer
developers control over the level and type of normalization nor the
ability to manipulate relative URIs without resolving them. Humanity
deserves a better foundation on which to construct algebras over its
global namespace.

As for speedy deployment, I would rather start on the path toward
correct, consistent, and powerful pattern matching than see something
rushed into standards due to feature anxiety. 3 or 6 more months to
get this language right is a constant factor on a potentially
unbounded technology lifetime.

I hope you've found this design proposal stimulating and I warmly
welcome any and all constructive (or destructive) response.

Happy Holidays,

David Sheets