- From: Adrian Sutton <adrian.sutton@ephox.com>
- Date: Mon, 28 Jul 2008 09:56:13 +0100
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/>
Received on Monday, 28 July 2008 01:56:13 UTC