On 7/9/07, Samuel Klein <[EMAIL PROTECTED]> wrote: > On Mon, 9 Jul 2007, Ian Bicking wrote: > > Yoric wrote: > >> On Mon, 2007-07-09 at 12:28 -0500, Ian Bicking wrote: > >>> The library protocol seems a bit odd to me. I think I understand the > >>> reasoning, but it opens up a lot of questions. What happens when two > >>> resources claim to have the same id? > >> Latest opened/added reference wins. > >>> If you have a link to library:something, and you've never seen that book > >>> before, how do you attain the book? > >> If there's no reference to the book in the database, an error page shows > >> up, asking the user to please locate the book using File:Open and try > >> again. > >>> If you want to move or discontinue a book, how can you do that? > >> If the reference to the book in the db is obsolete, the same error page > >> shows up.
> >>> I'd rather hijack http: for the same thing you are doing, but I get the > >>> impression creating a new protocol is relatively simple in comparison. > > With library: you are keying books off ids. http: is just keying books off > > the URI, which is a string just like the id is a string. It's okay to just > > treat it as a string. I would also rather see us use http:// as our protocol scheme. Http seems to answer three of the above questions: a) who owns the identifier 'http://cscott.net/ElectronicsTextbook' the people behind cscott.net, of course. this prevents id duplication. b) what happens if I don't actually have the ElectronicsTextbook on my machine the URI gives you a location where you can download it. (although we have a lot of flexibility about what content gets served from that URL -- it could just be a redirection or metadata of some kind) c) how do I tell if my ElectronicTextbook is the "real" ElectronicsTextbook I can always compare it to the canonical version, using (for example) http etags. I haven't heard the counter-argument for 'library:', so maybe I'm missing some compelling reason to invent our own protocol, but this seems like another case where we should be reusing rather than reinventing. --scott -- ( http://cscott.net/ ) _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
