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-". I don't think app is necessarily the most appropriate but it seems practical. We will add _many_ keys and the common prefix may save our bacon down the road.


 * Generic site agnostic preferences will be stored with a  prefix:

userjs-app-pref-version: "semver" userjs-app-pref-mtime: 0 userjs-app-pref-theme: "dark|light"
 * acts like a database version and allow us to make changes to the schema.


 * will be written to using a timestamp from a service data header when any other value is written. This will help avoid needless reconciliation in the client. However, conflicts when writing any key will be resolved as last write wins.
 * Collections will have the following key form:, where   is a number not a title. Collections will just describe title and privacy right now. Collection membership will be derived from page keys client side.
 * Pages will have the following key form:, where   , and, and   is a number not a title. The data structure is TBD but will be a superset of the Android implementation's database columns. Every page is represented as a key to keep writes small.


 * 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.

= 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. I'm thinking of allowing rows with identical pageids to allow for multiple collection memberships.
 * for string searches.
 * for history / recently viewed.
 * for recently added.
 * for collection to page membership queries.
 * for string searches.
 * true if content changes should trigger local notifications.
 * 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