e-Book reader

[Samuel Klein]

Moving the discussion devel; this is an interesting thread for other 
people there.  --SJ


On Mon, 9 Jul 2007, Ian Bicking wrote:

> Yoric wrote:
>> On Mon, 2007-07-09 at 12:28 -0500, Ian Bicking wrote:
>>> Hi Yoric.  I like the concept.  A few basic questions:
>>> 
>>> I've installed the extension, but invoking it is a bit confusing.
>>> 
>>> I tried downloading 
>>> http://superb-east.dl.sourceforge.net/sourceforge/openberg/Sganarelle.obz 
>>> but it only works if I first download it locally. 
>> 
>> Hmmm... that's strange. For me, it works directly from that URL. Can you
>> try with the latest release of Lector ?
>
> I downloaded the version linked to from the Lector homepage, version 5, 
> 2007.07.08.  Is that the wrong version?  It still just opens a blank page (it 
> doesn't ask if I want to download, so it must be doing something, I'm just 
> not sure what).
>
>>> There's a noticeable delay before the keys start working, which made me 
>>> think the whole thing was broken at first. 
>> 
>> Actually, the delay is enforced artificially. We need to tweak it a
>> little.
>>
>>>   Also on pages with only a single screen of content (e.g., the title 
>>> page) you have to hit page down twice.  Is there a way to get to an index 
>>> or table of contents?
>> 
>> That's our next feature. We should have this by end of August, with any
>> luck.
>> 
>>> Besides being a bit confused by the UI, I feel like this is generally a 
>>> good direction.  Deployment remains a bit of a mystery to me, but maybe 
>>> not to other people.  Yoric: what do you use to implement this? 
>> 
>> Er... all the ob*.js files depend on XPCom/XPConnect and a number of
>> XPCom components, all of which should be available in Firefox, XulRunner
>> and . The other .js/.xul files depend on Firefox itself but should be
>> relatively easy to replace.
>
> I think those are all fine, the only issue is how to actually deploy the 
> extensions.  That is, .xpi files don't work, but all the underlying pieces 
> are the same.
>
>>> Though maybe that's just an already existing feature whenever you link to 
>>> target="_search"?
>> 
>> Indeed. We might rewrite it to get the notes to appear on the right, but
>> the left-side panel is built-in Mozilla/Firefox.
>> 
>>> On the OLPC currently we aren't using Firefox, and so there's no clear 
>>> extension mechanism.  Which is what makes me wonder how much of an 
>>> extension mechanism do we need to make something like this possible? I'm 
>>> wondering if something like Greasemonkey plus a little extra would be 
>>> sufficient.
>> 
>> Oh, I thought Firefox 2 was included (as per
>> http://wiki.laptop.org/go/Firefox2 , Jim Gettys' previous mail, etc),
>> which sounded coherent with the references to PyXPCom. As for
>> Greasemonkey, afaik, it's a Firefox extension, so I assume you're using
>> something else underneath. What kind of "something else" ?
>
> I might be out of the loop, I'm not sure.  Is it planned to ship Firefox 2? 
> The page just looks like instructions on how to install it.  The Web activity 
> that I'm aware of uses Gecko and PyXPCOM, and I believe has all the other 
> components but a different wrapper.  I guess what Firefox is to Gecko, 
> Web.activity is to Gecko but with a Sugar/OLPC UI.
>
> And for the particular case of book reading, maybe it doesn't need to be an 
> extension at all, because it's something we want on every computer.
>
> For instance, should we just make Page Down scroll to the next page *always*, 
> when a next page is defined?  (You define next page in HTML with <link 
> rel="next" href="next-page">, so that's already well defined)
>
> It seems like there's already lots of preprocessing necessary to get a book 
> into the right format for Lector, so adding a little more preprocessing to 
> define the structure directly in the HTML files might be fine.
>
>>> 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?  (Maybe maliciously, or maybe just 
>>> the content is forked and someone forgot to update the id, or maybe they 
>>> can't agree on which is the "real" version.) 
>> 
>> 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.
>>
>>>  E.g., a book is forked under a new id, maintained, and the original isn't 
>>> maintained and goes out of date. 
>> 
>> A book with meta-data can have several IDs. So if your fork keeps being
>> maintained and the original goes out of date, you can hijack the ID of
>> the original and add it to your collection of IDs. 
>>> 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.
>> Well, this library: is closer to file: than to http:, not to mention
>> that a new protocol makes for a faster and less ambiguous result. 
>> If you have any question/suggestion, I'll be happy to answer. Note that
>> I'll be away from mail for about one week, though.
>
> 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.
>
> This article was influential in my personal desire to use http: for naming 
> things: http://norman.walsh.name/2006/07/25/namesAndAddresses
>
>
> -- 
> Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org
>            : Write code, do good : http://topp.openplans.org/careers