e-Book reader

[Samuel Klein]

On 7/9/07, C. Scott Ananian <cscott at cscott.net> wrote:
> 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

Using http:// does have great advantages.  I'm not sure ambiguity of
identifiers is one of our top problems... URIs are good at being
unique, as noted above; and you can never completely solve the problem
of people cloning materials and making new copies with new names that
are identical to the old materials.  It is useful to take advantage of
caching already in place for http:// .  And it is useful to be able to
view with a reader any accessible material with a URL, without special
preprocessing or database seeding.

SJ