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 _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
