USAGE SCENARIOS:
- Go to a wiki article, click to add that page to one's IndexedDB storage and/or offline cache, keyed to that article title.
- Go to a wiki category, click to add all pages under that category to one's IndexedDB storage and/or offline cache, keyed to that category.
- Use an auto-archive mode so that all visited pages will be archived and keyed to their article title and category and/or stored in the offline cache.
- Use offline HTML5 to access the entire Mediawiki app, with any such saved documents available while offline. Ideally, edits could also be cached and optionally submitted when connectivity was reestablished depending on conditions (using the API for Ajax storage ideally as well, since such an offline tool would be a modern app already, and would not need the page refreshes required by PHP form submissions, even allowing on some wikis, the ability to do real-time editing).
- Provide an HTML5 SharedWorker API to allow cross-domain access to its IndexedDB database, so that other applications could request user permission to access their locally stored files, and perhaps act as query engines or browsers of this data.
- Although a third-party API, especially with implementation of bug 28700 could do this if item #5 just above were implemented, it would be convenient for Mediawiki to have its own default offline query page, allowing users the ability to create XQueries (e.g., using the newly unfolding JavaScript-based XQIB http://xqib.org library) or evaluate arbitrary jQuery-based statements against IndexedDB-archived items, including the ability to specify querying against an entire collection (category) or all documents.
One might be able to search, for example, for
$('collection("Shakespeare") div[class=ironic]')
...to find all passages in the locally-stored Wikisource Shakespeare category/collection which were marked up as being ironic.
Or one could perform searches (and even joins using XQuery, JSLinq, https://github.com/nkallen/jquery-database etc.) to query HTML tabular data on Wikipedia's reference tables, for example:
$('doc() td:contains("345")'); // doc() being the current document context, or collection() being the current collection/category
...search through all of one's Wikibook texts, mash-up SVG documents on Commons, or do complicated transformations (without taxing or waiting for a server) which for example, join all letters from a certain author and put them in date order, if the markup specified such dates.
Though I used familiar jQuery examples, I think XQuery, besides being a standard, not only side-steps potential security problems with safely evaluating raw user jQueries, but also offers the more powerful XPath expressions (though admittedly it is not as conveniently extensible as allowing arbitrary JavaScript).
For places and countries with poor internet connectivity, such offline ability ought to still allow rich computer interaction offline, and maybe become a germ for decentralized, distributed wikis.
Version: unspecified
Severity: enhancement
Whiteboard: aklapper-moreinfo