On 4/16/07, Ian Bicking <[EMAIL PROTECTED]> wrote: > There's the library itself, which is what you get as the home page when > you open up the browser. I believe this is all done just as static > HTML, and I believe the UI is just transitional, it's not intended as > the final implementation. I'm not sure how that relates to > ebook-browser-reader. Huh.
ebook browser reader looks like a spike implementation of a js based reader. I've emailed the author directly and I'll find out where that project is at. > Anyway, there definitely will be HTML content that should have a good > reading experience, which implies something browser-based. Though > there's been discussion of whether the browser activity in particular > should be the basis of that. The line between browsing and reading > extended works seems fuzzy to me; creating a distinction by having two > activities would seem unfortunate. Definately. Reading extended works in the web browser is also very hard to do. Long web pages are almost impossible to keep your place in. This is the motivation for something js based like the ebook-browser-reader I think. > Something that I think would be excellent is if the browser had UI > specifically related to some of these link types: > http://www.w3.org/TR/html401/types.html#type-links -- these identify the > position of a page in a book-like structure fairly well, I think, and > having the browser actually pay attention to that should make it easier > to translating a book into HTML. > > I imagine better bookmarking of some sort would also be helpful -- > ideally you'd be able to save your exact position so you can return to > it. The journal would save that position (once the journal is > implemented), but regardless of that the browser has to be able to tell > the journal the position and then be able to return to it later. Having investigated the memory footprint of the web browser on the beta2 machines, it's currently quite heavy. My biggest fear with using it for ebook reading is that if it gets OOMKilled, then the page will be lost, and that be a disaster. What I was thinking was possibly using the web browser and a local light weight http server of some kind (SimpleHTTPServer or something) that would serve ajaxy data to the web browser and integrate with things like the journal. This way even if the Web activity with its MozEmbed component dies via OOM, the backend store can still be written (and the backend store can take SIGDANGER signals and cache that data to disk). That all said, the sophieproject looks very promising (and is BSD licensed) so I'm currently wanting to investigate that. -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange _______________________________________________ Sugar mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/sugar
