Re: Offline Web Applications status

IndexedDB would be more suited to what you're doing Nathan, I've always seen
ApplicationCache as something to only use on the core HTML/JS/CSS and perhaps
small images, like icons (none of this would change often, and would generally
be rather small) whereas IndexedDB sounds more like what you did with gears.

Or, there's always the File System API, but I don't think it's widely
implemented yet.

Excerpts from Nathan Kitchen's message of Sun Mar 27 08:46:35 +1100 2011:
> A couple of other app cache observations from a hobbyist who's played around
> with Google's Gears...
> 
> I built an offline web application based on Gears, with the intention to
> migrate to something a bit more standardized as it became available. That
> was a good two years ago now, but the existing and proposed implementations
> still don't offer the capability that I can get from Gears.
> 
> If you're in Chrome, point your browser at: http://my.offlinebible.com/. My
> observations are going to be related to this app. I apologise if they're
> quite specific, but they present a snapshot of some real-world issues
> encountered while developing an offline app.
> 
>    - *App Cache*
>    The first task that the app undertakes is downloading a large amount of
>    offline data. This data includes the usual web page resources, plus a
>    massive amount of data destined for the Gears/WebSQL database.
> 
>    Ideally, I want to keep this in a single easy installation process. With
>    Gears I can do this entirely from JavaScript. First, the database is set up.
>    Then, AJAX is used to request data in chunks (JSON, about 60Mb, gzipped for
>    bandwidth gets it down to 10Mb iirc). Once it's all requested, it gets
>    dropped into Gears/WebSQL. Finally all the usual web assets (html, css, js,
>    img) are cached. Throw up a progress bar, run everything in a web worker to
>    keep the UI from freezing, done.
> 
>    With the existing specs, I'd have to do something slightly different.
>    First, I'd have to hit a page with a manifest, and hook the relevant events
>    for when the cache was ready. If I want to offer the user different offline
>    capabilities (i.e. customize what's cached), afaik I can't do that from
>    JavaScript. It requires some server-side code/processing to output a
>    different manifest.
> 
>    Once the cache was ready, I could carry on with the existing
>    installation. However, I don't (think I) have the script-side control over
>    adding and removing items from the cache to customize the user's offline
>    experience.
> 
>    - *Search
>    *This is the use-case that's most important to me. I want to be able to
>    search all the data which I took offline. My current implementation is built
>    using manually indexed items and joins. In theory I could use the full-text
>    capabilities of the underlying SqlLite Gears implementation, but this was a
>    step too proprietary for me. I built all the data indexes to see what
>    performance was like. Throw some words into the search capability, you'll
>    see how long it takes to search. It's *fairly* quick but there's a slight
>    lag (which locks the UI, it's synchronous ATM).
> 
>    I know full-text indexing is on the cards for IndexedDB. I'd love to see
>    some sample implementations of full-text to compare speed against the manual
>    index. For single words there might not be too much difference, but for more
>    complex multi-word or pattern-matching, the manual index is too
>    slow/won't work.
> 
> I don't think that my scenario is particularly unusual. Taking a large
> amount of data offline and making it available to search seems like a pretty
> common use-case. To support this, there are three capabilities which I'd
> like to see:
> 
>    - Script access to add or remove items from the application cache -
>    document.manifest.add("");
>    - Batch operations (or support for adding a lot of similar data as
>    quickly as possible - this takes ages if you add each record as a single
>    transaction)
>    - Full-text search on data
> 
> I'm looking forward to this coming together eventually, might be worth an
> IndexedDB implementation soon : )
> 
> On 24 March 2011 05:53, David John Burrowes
> <bainong@davidjohnburrowes.com>wrote:
> 
> > 2011/3/24 louis-rémi BABE <lrbabe@gmail.com>
> >
> >> ## Maybe Web devs don't use App Cache because they don't understand
> >> what it is... ##
> >>
> >
> > I think most webdevs are expecting more than what is offered. It seems like
> > a half baked solution to a potentially useful requirement.
> >
> >
> > I thought I'd add half a cent here, from the perspective of one who isn't a
> > professional web developer... just a hobbyist.
> >
> > When I heard about the app cache, it seemed like a really great thing.
> > Offline web apps! Cool! A way for the web to become even more ubiquitous!
> >
> > But, as the comment above hints, it really doesn't seem to be the full
> > delivery of the solution (even when you get past the browser differences,
> > setting up of mime types, debugging all this, etc).  An offline web app is
> > certainly more than just caching the code and ui files, no?  It is also some
> > kind of stand-in for the absent server... data storage, and cross-page state
> > of some sort (e.g. I'd expected something like web workers that can live for
> > a session, not a page).  These aren't all coming together at the same time,
> > and aren't really being presented as a unified "feature" (indeed, I'm not
> > sure that they are being thought of as that)
> >
> > I'm sure that as html continues it's forward evolution, these will all come
> > into play and we'll eventually see more use of the feature.
> >
> > David
> >
> >
> >