e-Book reader

[C. Scott Ananian]

On 7/9/07, Samuel Klein <sj at laptop.org> 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/ )