[whatwg] Application deployment

[Kristof Zelechovski]

My complaint was about how the jar URL scheme wannabe conceptually differs
from the schemes we already officially have, not about how ugly it is to
have two consecutive colons.  It is ugly but it does not matter.  What
matters is that a scheme is being promoted that is specific to one content
type, just as the APPLET element is discouraged for the same reason.
Content types and URL schemas should not be coupled because they live in
different worlds.  The jar scheme is an exception in Java just as the
javascript scheme is an exception in HTML because these are essential for
the internal mechanisms of either language.  Java does not recognize the
javascript scheme; why should HTML recognize jar?  Because Java programmers
use it extensively?  Even if that is true, which I doubt (because I think
there should be a more abstract API for getting application resources
anyway, perhaps using jar in the implementation), it hardly matters for
HTML.

I think dealing with two fragment identifiers is a lesser evil than turning
the URL upside down.

The difference between a hierarchical file system and a flat file system are
minute indeed and it is primarily related to search efficiency: traversing a
directory tree in logical order is straightforward in HFS but requires a
prior conversion in FFS; HFS directories are inaccessible (without server
extensions) but FFS "directories" simply do not exist.

If relative locators are allowed to go out of the jar (relative to the
directory the jar is in) then all internal hyperlinks into the archive must
be "#full/path#fragment" and all local links must be "##fragment".  That
means the code base must be preprocessed before packaging.

Anyway, it is not obvious at all that linking inside a packaged HTML
application should be supported.  An alternative solution would be to
indicate the start page in the manifest and let the code run under a fake
root.

IMHO,

Chris

  _____  

From: Adrian Sutton [mailto:adrian.sutton at ephox.com] 
Sent: Monday, July 28, 2008 10:56 AM
To: Kristof Zelechovski; Adam Barth
Cc: whatwg at whatwg.org; Russell Leggett; Philipp Serafin
Subject: Re: [whatwg] Application deployment

 

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/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080728/f2abca93/attachment-0001.htm>