[whatwg] Application deployment

Mon Jul 28 12:19:36 PDT 2008

Although jar, mhtml, and also the widget spec have some related ideas, I
think all of them are more complex than the solution I'm suggesting as well
off target. I will give a full example.

Let's say I have a large javascript application that is broken into several
files for better organization.

<script type="text/javascript" src="/js/file1.js"></script>
<script type="text/javascript" src="/js/file2.js"></script>
<script type="text/javascript" src="/js/file3.js"></script>
<script type="text/javascript" src="/js/file4.js"></script>
<script type="text/javascript" src="/js/file5.js"></script>

This could easily be more, but you get the drift.

But let's say we could zip up all the files, and retrieve them at the start
of an html document:

<!-- somewhere in the <head> tag -->
<link rel="resources" href="/js-files.zip"/>

This zip might contain a directory "js" and inside would contain the js
files. When the zip file was loaded with the link tag, it would immediately
be unzipped and the files would be put in the cache as though they were
loaded individually. None of the javascript or other resources would be
executed or processed, they would simply be added to the cache. Later in the
html document, these resources could be pulled from the cache.

<head>
<title>My web app</title>
<link rel="resources" href="/js-files.zip"/>

<script type="text/javascript" src="/js/file1.js"></script>
<script type="text/javascript" src="/js/file2.js"></script>
<script type="text/javascript" src="/js/file3.js"></script>
<script type="text/javascript" src="/js/file4.js"></script>
<script type="text/javascript" src="/js/file5.js"></script>
</head>

Notice that the script tags stay the same with or without resources link. If
it was not supported, it could easily be ignored and the page would still
work. In addition to script tags, this could easily work with css and images
as well as any other resources.

On Mon, Jul 28, 2008 at 2:21 PM, Kristof Zelechovski
<giecrilj at stegny.2a.pl>wrote:

>  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<http://www.example.com/site.jar#/path/inside/foo.html%23heading1>
>
>
> > 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/7776bf73/attachment-0001.htm>