<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Re: [whatwg] Application deployment</title>
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;}
p
{mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman";}
span.Stylwiadomocie-mail18
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:595.3pt 841.9pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=PL link=blue vlink=blue>
<div class=Section1>
<p class=MsoNormal><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.<o:p></o:p></span></font></p>
<p class=MsoNormal><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.<o:p></o:p></span></font></p>
<p class=MsoNormal><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.<o:p></o:p></span></font></p>
<p class=MsoNormal><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.<o:p></o:p></span></font></p>
<p class=MsoNormal><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.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:navy'>IMHO,<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:navy'>Chris<o:p></o:p></span></font></p>
<div>
<div class=MsoNormal 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 tabindex=-1>
</span></font></div>
<p class=MsoNormal><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:adrian.sutton@ephox.com] <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> whatwg@whatwg.org; Russell
Leggett; Philipp Serafin<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [whatwg] Application
deployment</span></font><o:p></o:p></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></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"
<giecrilj@stegny.2a.pl> wrote:<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#heading1">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/">http://www.ephox.com/</a>><br>
Ephox Blogs <<a href="http://planet.ephox.com/">http://planet.ephox.com/</a>>,
Personal Blog<br>
<<a href="http://www.symphonious.net/">http://www.symphonious.net/</a>></span></font><o:p></o:p></p>
</div>
</body>
</html>