Per-Account Application Support Storage Area
Short, concise description of the idea
Allow LJ client applications to share configuration data on a per-account basis.
Full description of the idea
There have been suggestions in the past for many features (recently, auto-linking keywords when posting) that do not belong on the server side of Livejournal. However, many clients would like to implement such features, and it would make sense to share the configuration aspect of such features, if not the implementation itself (which still needs to happen on a client-by-client basis).
- Allows common account preferences for LJ client applications to be stored in one place.
- Encourages innovative features, while allowing such features to be re-implemented across any client that wants to do so.
An ordered list of problems/issues involved
- Coming up with a data model and API - I would recommend a REST-style API (if it fits in the current LJ API -- I'm not a developer so I don't know the details).
- Implement this. Conceptually, it's pretty simple: every account has a table with a key name (the index column), a MIME type (allows data tagging and is REST-friendly), and a blob for the data.
- Determining the allowed size of the application configuration support area.
- Determining if community accounts get this kind of storage.
- For off-line usability, a client would want to implement a scheme where the account configuration data could be cached, and perhaps even updated, locally.
Managing the namespace of keys for application configuration. I would suggest, if there's no prior art in the Livejournal API, using a reverse-DNS naming convention for keys, as in Java or the Mac OS X preference API.
- Coordinating and advertising the use of these keys so that different clients can re-use configuration data instead of reinventing the wheel.
An organized list, or a few short paragraphs detailing suggestions for implementation
- Probably the simplest model would be to have a name-keyed association table of storage blobs, tagged with a MIME type. For synchronization with a locally-stored version of the configuration data, a last-modified time and other metadat might be neccessary.
- LJ could maintain a repository of well-known keys that client developers could consult. I could imagine that there are already of a set of attributes that most clients implement, and it would take some coordination to define a set of these keys.