<div dir="ltr"><div>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.</div><div>
<br></div><div>Let's say I have a large javascript application that is broken into several files for better organization.</div><div><br></div><div><br></div><div><script type="text/javascript" src="/js/file1.js"></script></div>
<div><script type="text/javascript" src="/js/file2.js"></script></div><div><script type="text/javascript" src="/js/file3.js"></script></div><div><script type="text/javascript" src="/js/file4.js"></script></div>
<div><script type="text/javascript" src="/js/file5.js"></script></div><div><br></div><div>This could easily be more, but you get the drift.</div><div><br></div><div>But let's say we could zip up all the files, and retrieve them at the start of an html document:</div>
<div><br></div><div><!-- somewhere in the <head> tag --></div><div><link rel="resources" href="/js-files.zip"/></div><div><br></div><div>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.</div>
<div><br></div><div><head></div><div><title>My web app</title></div><div><link rel="resources" href="/js-files.zip"/></div><div><br></div><div><script type="text/javascript" src="/js/file1.js"></script></div>
<div><script type="text/javascript" src="/js/file2.js"></script></div><div><script type="text/javascript" src="/js/file3.js"></script></div><div><script type="text/javascript" src="/js/file4.js"></script></div>
<div><script type="text/javascript" src="/js/file5.js"></script></div><div></head></div><div><br></div><div>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.</div>
<br><div class="gmail_quote">On Mon, Jul 28, 2008 at 2:21 PM, Kristof Zelechovski <span dir="ltr"><<a href="mailto:giecrilj@stegny.2a.pl">giecrilj@stegny.2a.pl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="PL" link="blue" vlink="blue">
<div>
<p><font size="2" color="navy" face="Arial"><span lang="EN-US" style="font-size:10.0pt;font-family:Arial;color:navy">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.</span></font></p>
<p><font size="2" color="navy" face="Arial"><span lang="EN-US" style="font-size:10.0pt;font-family:Arial;color:navy">I think dealing with two
fragment identifiers is a lesser evil than turning the URL upside down.</span></font></p>
<p><font size="2" color="navy" face="Arial"><span lang="EN-US" style="font-size:10.0pt;font-family:Arial;color:navy">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.</span></font></p>
<p><font size="2" color="navy" face="Arial"><span lang="EN-US" style="font-size:10.0pt;font-family:Arial;color:navy">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.</span></font></p>
<p><font size="2" color="navy" face="Arial"><span lang="EN-US" style="font-size:10.0pt;font-family:Arial;color:navy">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.</span></font></p>
<p><font size="2" color="navy" face="Arial"><span lang="EN-US" style="font-size:10.0pt;font-family:Arial;color:navy">IMHO,</span></font></p>
<p><font size="2" color="navy" face="Arial"><span lang="EN-US" style="font-size:10.0pt;font-family:Arial;color:navy">Chris</span></font></p>
<div>
<div align="center" style="text-align:center"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">
<hr size="2" width="100%" align="center">
</span></font></div>
<p><b><font size="2" face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;font-weight:bold">From:</span></font></b><font size="2" face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma"> Adrian Sutton
[mailto:<a href="mailto:adrian.sutton@ephox.com" target="_blank">adrian.sutton@ephox.com</a>] <br>
<b><span style="font-weight:bold">Sent:</span></b> Monday, July 28, 2008 10:56
AM<br>
<b><span style="font-weight:bold">To:</span></b> Kristof Zelechovski; Adam
Barth<br>
<b><span style="font-weight:bold">Cc:</span></b> <a href="mailto:whatwg@whatwg.org" target="_blank">whatwg@whatwg.org</a>; Russell
Leggett; Philipp Serafin<div class="Ih2E3d"><br>
<b><span style="font-weight:bold">Subject:</span></b> Re: [whatwg] Application
deployment</div></span></font></p>
</div>
<p><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> </span></font></p>
<p style="margin-bottom:12.0pt"><font size="2" face="Times New Roman"><span style="font-size:10.0pt">On 28/07/2008 09:22, "Kristof Zelechovski"
<<a href="mailto:giecrilj@stegny.2a.pl" target="_blank">giecrilj@stegny.2a.pl</a>> wrote:<div><div></div><div class="Wj3C7c"><br>
> Having this URL monster shipped does not preclude replacing it with a more<br>
> logical one and deprecating the original one. People make mistakes
all the<br>
> time and fortunately there are cases where the harm can be undone.<br>
<br>
It's not just FireFox that supports this URL scheme - the entire Java world<br>
uses it and supports it back as long as JAR files have existed as far as I<br>
know. While web pages are a different domain it seems silly to have two<br>
completely different notations for the same thing just because of aesthetic<br>
reasons.<br>
<br>
It's also worth noting that the jar: scheme will allow you to target anchors<br>
in a HTML document that's within the archive where as the fragment<br>
identifier syntax would not, unless you used two fragment identifiers:<br>
<a href="http://www.example.com/site.jar#/path/inside/foo.html%23heading1" target="_blank">http://www.example.com/site.jar#/path/inside/foo.html#heading1</a><br>
<br>
<br>
> Of course this means that the way relative locators inside an archived<br>
> document are handled must be changed (they should apply to the fragment
and<br>
> not to the archive path); it should not be possible to escape an archive<br>
> following relative hyperlinks.<br>
<br>
Why not? It seems reasonable to have some things inside the JAR and some<br>
dynamically created outside of it. For example were Gmail wanting to reduce<br>
the initial download time for it's JavaScript and UI resources it could put<br>
them in a JAR file but the JavaScript would still want to send requests to<br>
retrieve the user's actual mail data. It could use an absolute URL to do it<br>
but why not support relative URLs?<br>
<br>
> It should also be noted that such an archive has a flat file system (only<br>
> one directory with files tagged with relative paths rather then plain
names)<br>
> whereas the HTTP path component addresses a hierarchical file system with<br>
> true directories. It can cause relative hyperlinks to break when
archiving<br>
> an existing directory.<br>
<br>
The file system inside a JAR or ZIP is strictly speaking flat, but logically<br>
hierarchical - ie: you unzip it and you get a hierarchy of directories. The<br>
actual method of storage in bits and bytes doesn't seem to matter. Perhaps<br>
I'm misunderstanding your point...<br>
<br>
Regards,<br>
<br>
Adrian Sutton.<br>
______________________<br>
Adrian Sutton, CTO<br>
UK: +44 1 753 27 2229 US: +1 (650) 292 9659 x717<br>
Ephox <<a href="http://www.ephox.com/" target="_blank">http://www.ephox.com/</a>><br>
Ephox Blogs <<a href="http://planet.ephox.com/" target="_blank">http://planet.ephox.com/</a>>,
Personal Blog<br>
<<a href="http://www.symphonious.net/" target="_blank">http://www.symphonious.net/</a>></div></div></span></font></p>
</div>
</div>
</blockquote></div><br></div>