[sword-devel] HTML5 File API and SWORD modules

[Matěj Cepl]

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
> binary data in JavaScript to be a little bit of a dark art because it
> 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 
pure Javascript (https://github.com/mozilla/pdf.js ... I use it 
everyday, and it just a bit slower than binary viewers, certainly quite 
useable) and MP3/AAC/FLAC/WAV players in pure Javascript 
(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 
https://developer-new.mozilla.org/en-US/docs/DOM/XMLHttpRequest/Sending_and_Receiving_Binary_Data, 
https://developer-new.mozilla.org/en-US/docs/JavaScript_typed_arrays/ArrayBuffer, 
https://developer-new.mozilla.org/en-US/docs/JavaScript_typed_arrays and 
related pages).

> 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 
not in).

> 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
> APIs.

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
> JavaScript framework like ExtJS (GPLv3 or commercial) or Qooxdoo (LGPL
> 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 
Javascript ... the result is a shameful mess, not enough OOP (because 
none of the classical class inheritance shills are any good) and 
certainly not good JavaScript. My experience is that I could do all what 
I need with a plain prototypical inheritance and ES5 improvements.

Best,

Matěj

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