Yoric wrote: > Okay, as my message seems to have bounced from devel, I'll try again. > > I believe that hijacking an existing, standard, protocol (here http) is > a bad idea. Firstly, because turning standard protocols into hack > versions that sometimes work as per the standard and sometimes don't is > usually opening a can of worms. Who knows what that is going to break ? > Who can tell exactly what depends on the correct behaviour of http ? Not > to mention that there's a whole bunch of things you need to reimplement > by yourselves if you want to use http. In practice, from my experience > of Mozilla's source code, you'll have to reimplement caching, > authentification, redirections, etc. That's quite the opposite of the > expected benefits of hijacking.
Really we're just talking about increasing the caching and providing the user more access to control that cache. So it's not that substantial of a change. HTTP doesn't make any firm guarantees about how content is delivered. Proxying is very common, and really we're talking about a proxy (though one implemented directly in the browser... which I guess isn't a "proxy" but an actual client... but the same ideas apply). We could also implement it as a formal proxy hosted directly on the laptop. Just in terms of implementation I think it would be better to do directly in the browser since the process isn't completely transparent, maybe with a DBus API if we want to make the same caching system available to other applications. > Secondly, hacking http means that you rely only on http. That's good if > you only want to download books from http servers. But what about the > other important protocols such as file: ? Are you also going to hack > file: ? What about ftp: ? file: doesn't have to be modified, since it's locally available and doesn't need to be cached. ftp and other protocols don't really matter, IMHO. > Thirdly, using a hacked http: (or file: or ftp:) means the subtle yet > annoying problem of referencing resources (say particular pages or > images) inside a book. In > http://mydomain.org/a/b/c/d > what part of a/b/c/is the directory containing the book ? What part is > the identifier of the book ? What part is the name of the resource ? > What if resource names involve directories ? Etc. Sure, you can solve > the problem by using smart conventions on URLs or by toying with > exclamation marks, interrogation marks and sharp signs but I suspect > that you'll quickly end up with having to hack the very notion of URL > away from what's used in http: . And it gets worse if your books may be > generated or delivered dynamically -- hence involving interrogation > marks for queries -- or if some resources inside the book may be > generated or delivered dynamically or, even worse, if books may contain > books. I don't really understand the problem here at all. Why is it hard to know where the "book" is? I put in scare quotes, because a book is not a distinct thing online -- a book can easily be split or combined into volumes online, so its distinct identity is unclear. Anyway, a simple way to do referencing is relative links. The book pages need to understand the internal structure of how they were generated -- e.g., if the book is a flat set of pages, just linking to "./" will get to the "root" of the book. If you need to tell clients the structure of the book, HTML already has standards for this, like <link rel="index" href="...">. Well constructed books can use those existing conventions. I guess why I'm confused by this is that all the problems you mention are the problems we are all very familiar with in creating content on the web. And there's lots of conventions and solutions and tools to address these problems. > By opposition, the library: protocol > * doesn't break anything > * can work together with any delivery protocol (we're using mostly http: > and file:, but also jar: for decompression and we hope we'll be able to > use some peer-to-peer protocol in the future for distributed libraries) > * already takes advantage of Mozilla's caching > * resolves ambiguities between book identifier / resources inside the > book / book inside book / etc. > > > The one downside I see about library: is the possibility of having two > different books with the same "unique" identifier. And I'm confident > there's a way to find workarounds. Perhaps by making the *identifier* -- > and only the identifier -- a nicely encoded URL. > > Say, something like > library:mydomain.org!a!b/c/d > being automatically turned into > http://mydomain.org/a/b > for downloading/authentification purposes. Here, I assume that http is > the default downloading mechanism. Other non-default protocols may be > specified. Note that I'm avoiding %-based encodings only for readability > purposes. If readability is not a problem, we can use directly that > standard encoding. This is where I have to start thinking -- if we're encoding an HTTP URI in the library URI, why not just stick with HTTP from the beginning? -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
