https://bugzilla.wikimedia.org/show_bug.cgi?id=28706
Bug #: 28706
Summary: Allow post-parsed documents to be available offline
and saved into IndexedDB and made queryable
Product: MediaWiki
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General/Unknown
AssignedTo: [email protected]
ReportedBy: [email protected]
Classification: Unclassified
USAGE SCENARIOS:
1) Go to a wiki article, click to add that page to one's IndexedDB storage
and/or offline cache, keyed to that article title.
2) 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.
3) 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.
4) 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).
5) 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.
6) 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.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
