[sword-devel] HTML5 File API and SWORD modules
mcepl at redhat.com
Tue Jul 31 14:15:58 MST 2012
On 31/07/12 15:22, Greg Hellings wrote:
> since I looked into the limitations of browsers and their file APIs.
> As long as it can read and write binary files, it should have no
> problem with the files themselves. I have always found manipulating
> is so infrequently attempted as to be little documentation of it.
I think the situation with the latest browsers (mainly Firefox and
Chrome) is getting really better. After all there is now PDF viewer in
everyday, and it just a bit slower than binary viewers, certainly quite
(http://labs.official.fm/codecs/ ... quality is a bit questionable for
classical music, but certainly good enough for spoken word). Yeah, the
documentation will be difficult to get (aside from Use The Source, Luke™
and stuff on MDN like
> storage system, as I have read it, just stores a JSON-like object for
> retrieval. The only problem becomes requesting the browser for
I think you are bit behind the times ... it used to be so, but look at
links I sent in my previous message (this elephant
http://robnyman.github.com/html5demos/indexeddb/ is not a JSON string,
and yet it resides in the IndexedDB database; look at the URL of the image).
When I was asking Boot2Gecko people (who are of course interested in
such things) about possibility of writing pure HTML5 podcatcher (and
storing whole podcasts in the IndexedDB I was told that there is no
artificial limit on size of blobs/files stored via IndexedDB (actually
> additional storage when you reach the 5MB or 25MB limit or wherever it
> is set.
Those are limits on storing data IN the IndexedDB, not Files and Blobs.
> entirely different UI already and it probably doesn't support the File
Firefox for Android and B2G do. I would think that Chrome for Android
should do as well (but not sure, I don't use it).
> My own forays into this area have taught me that it's best to write
> using a framework where you can easily abstract your application away
> from the particular storage mechanism you put into place. Using a big
> or Eclipse PL) or similar allows you to get a traditional class
> inheritance structure and hide details like the storage implementation
> from your application. You might need to write a few different
> versions of that class to handle the different browser configurations
> around, but in the end it is probably worth it to help keep your
> sanity and provide increased portability in the future to your app.
I have my worst experience with frameworks (especially jQuery, but
others as well) ... they have plenty of bugs, and then you don't know
where to start debugging, whether in your program or in the framework
itself. And you certainly don't want to classical class inheritance with
none of the classical class inheritance shills are any good) and
I need with a plain prototypical inheritance and ES5 improvements.
http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
This conversation can serve no purpose anymore. Good bye.
-- HAL9000 in 2001: Space Odyssea
More information about the sword-devel