User:Niedzielski/App options

Options

 * Options are any kind of preference and include app collections of pages on any wiki, theme information, and other settings. They're not Gather Collections, although like Gather, we intend to store our own lists of pages in options.


 * All options regardless of locale will be stored on meta.wikimedia.org.


 * All keys added by app folk will be prefixed with "userjs-app-". App isn't necessarily the most appropriate but it seems practical. _Many_ keys will be added and the common prefix may save our bacon down the road.


 * AFAIK, options must be read altogether. Please correct me if I'm wrong! If you have 2 MB of user options and want to read only one key, you must download 2 MB. If we store recents, this means scenarios of thousands of keys will be common. Writing options, however, may be performed at any level of granularity.

Pref
Generic site agnostic preferences will be stored with a  prefix: ... userjs-app-pref-version: "semver" userjs-app-pref-revision: 0 userjs-app-pref-theme: "dark|light" ... acts like a database version and allow us to make changes to the schema. will be written with a random number when any other value is written. This will help avoid needless reconciliation from the client when reading. However, conflicts when writing any key will be resolved as last write wins.

Collection
userjs-app-collection-{collectionid}: { title: "" } is a number not a title. Collections are assumed private right now. Collection membership will be derived from page keys client side.

Page
userjs-app-page-{dbname}-{pageid}: { title: "" mtime: 0 atime: 0 collectionIds: [] watched: false saved: false }  and   is a number not a title. Every page is represented as a key to keep writes small.

Android implementation

 * The Android implementation will leverage a SyncAdapter, stub Account (will be upgraded to a full blown account[3] once we revisit auth), and a ContentProvider backed by SQLite database (just another table in the app's existing database).


 * The database structure has some flexibility in representation that will allow us to manipulate collections easily. Here are the columns I'm thinking currently:
 * for applying updates from a bulk read.
 * for querying all pages on a given wiki.
 * for page to collection membership queries and vice versa. Not necessarily unique in the table.
 * collection
 * page
 * for string searches.
 * for recently added.
 * for history / recently viewed.
 * true if content changes should trigger local notifications.
 * true if content should be precached.
 * true if content should be precached.

If userjs options seem kind of hacky it's because we're trying to do a lot more with them than they were designed for.

= References =
 * API:Options
 * API:Userinfo