[whatwg] Application deployment

[Adrian Sutton]

On 28/07/2008 09:22, "Kristof Zelechovski" <giecrilj at stegny.2a.pl> wrote:
> Having this URL monster shipped does not preclude replacing it with a more
> logical one and deprecating the original one.  People make mistakes all the
> time and fortunately there are cases where the harm can be undone.

It's not just FireFox that supports this URL scheme - the entire Java world
uses it and supports it back as long as JAR files have existed as far as I
know. While web pages are a different domain it seems silly to have two
completely different notations for the same thing just because of aesthetic
reasons.

It's also worth noting that the jar: scheme will allow you to target anchors
in a HTML document that's within the archive where as the fragment
identifier syntax would not, unless you used two fragment identifiers:
http://www.example.com/site.jar#/path/inside/foo.html#heading1


> Of course this means that the way relative locators inside an archived
> document are handled must be changed (they should apply to the fragment and
> not to the archive path); it should not be possible to escape an archive
> following relative hyperlinks.

Why not? It seems reasonable to have some things inside the JAR and some
dynamically created outside of it. For example were Gmail wanting to reduce
the initial download time for it's JavaScript and UI resources it could put
them in a JAR file but the JavaScript would still want to send requests to
retrieve the user's actual mail data. It could use an absolute URL to do it
but why not support relative URLs?

> It should also be noted that such an archive has a flat file system (only
> one directory with files tagged with relative paths rather then plain names)
> whereas the HTTP path component addresses a hierarchical file system with
> true directories.  It can cause relative hyperlinks to break when archiving
> an existing directory.

The file system inside a JAR or ZIP is strictly speaking flat, but logically
hierarchical - ie: you unzip it and you get a hierarchy of directories. The
actual method of storage in bits and bytes doesn't seem to matter. Perhaps
I'm misunderstanding your point...

Regards,

Adrian Sutton.
______________________
Adrian Sutton, CTO
UK: +44 1 753 27 2229  US: +1 (650) 292 9659 x717
Ephox <http://www.ephox.com/>
Ephox Blogs <http://planet.ephox.com/>, Personal Blog
<http://www.symphonious.net/>