[sugar] eBook software

[Stephen Thorne]

On 4/16/07, Ian Bicking <ianb at colorstudy.com> 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