[sword-devel] HTML5 File API and SWORD modules

[Greg Hellings]

On Tue, Jul 31, 2012 at 4:15 PM, Matěj Cepl <mcepl at redhat.com> wrote:
> 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).

It's certainly possible. But assuming you want to be Supported
Everywhere, you're going to have to work with the binary data in
special ways. My only point was that JavaScript is not always
straightforward with its ways to work with binary data since it was an
afterthought - especially in a browser environment.

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

The URL of the image is "elephants.png", which is hardly conclusive
evidence. :) Possibly because the page throws an error in Chrome when
it attempts to load the image into the IndexDB.

And my point still stands that it is storing a JSON-like object. Not
pure JSON, but what you have is an object store and not a relational
store. That allows particular elements of the object to be something
other than a string. I wasn't trying to be technical about the nature
of JSON vs the objects that IndexDB holds but rather point out that it
is very flexible in ways that are often easier to conceive of than a
SQL relational database.

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

Good to know. So there is no limit on putting a blob into the IndexDB?
That could lead to some very powerful offline apps. But I can't
imagine browser writers wouldn't limit the size of data stored
somehow. They wouldn't just allow you to keep creating data upon data
in stores until you fill a hard drive... at least I would hope not.

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

That's good, but for the other 99.5% of us who use Mobile Safari or
the built-in Android browser when we're on a mobile device, how do we
stack up? I ask in earnestness because I haven't tackled mobile web
development beyond a single failed foray in 2007.

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

Well, to each their own. I have found all of the base libraries
(except Ext which I use continuously at work) to be excellent.
Oftentimes they have terrible plugins or addons. And I never liked
prototype inheritance _instead of_ traditional inheritance. I like to
combine them the way that frameworks allow me to mix and match as I
see fit. I often will use a combination of raw language features,
jQuery's simplification of DOM traversal, and a full library's
inheritance and base widget libraries. But there's no accounting for
personal preference or ease of use.

--Greg