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 : [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
