[pittendrigh]

RE> "The future of multi-media ebooks is iOS/Android apps (with offline capabilities). Not browser-based, server-side php/asp that requires full-time connectivity. *shrug*"

Yes of course. A browser based reader is useful only for marketing, as a quick and dirty way to get potential buyers sucked in . I sell digital blueprints for do-it-yourself boat builders. Many if not most of my customers don't use Ebook apps yet. A browser based reader is a way to get them started.

Once they've seen the first 25 pages online they're supposed to get itchy fingers and buy the ebook as a whole, download it, then download Readium or what ever, then use a file browser to drag the ebook into the reader interface.

All of the above is forgotten by tech/savvy readers who already live in the brave new ebook world. For those who don't ebooks are a sales blockade.

======
I said I'd have working software by early January. I do now. I'm down to details. I've come this far already so I intend to finish what I started. But I am having regrets.

I wanted to be able to display an ebook (epub3 specifically) inside my own home-rolled Content Management System, so the ebook amounts to the contents of a DIV--so it could be surrounded by global navigation to all the other parts of my site.

Existing software like the javascript based bibi something insists on making HTML HEAD and BODY elements, so you cannot embed it without an IFRAME.

My software can be embedded. But the programming details are getting ugly. I have to do a lot of regular expression text substitution to *.xhtml content pages to get images video and sound files to work. That's server cycle expensive. Server side caching (like the resource expensive DRUPAL) will be required before it's a usable product.

Using the open source bibi software (don't have the link at my fingertips) with an IFRAME is starting to look more enticing. Prejudice against IFRAMES may be overblown. Somewhat like the C-programmer's aversion to gotos. Which aren't so bad in some contexts.