[Architecture] gsettings prototyping

Colin Clark colinbdclark at gmail.com
Wed Feb 22 19:17:48 UTC 2012

Hi Steve,

We've talked about about most of these questions in person at the developer meetings, but I thought it would be worthwhile to answer here on the list, just so we have a record of it. Comments below...

On 2012-02-07, at 9:53 PM, Steven Githens wrote:

> Outside of that usual stuff, I think the most valuable thing on your list below would be identifying, as explicitly as possible, the real preferences for the first 2 use cases (screen magnifier and reader).  I think having those concrete use cases nailed down will allow us to finish fleshing out the demo so we can begin to start filling the middle pieces in with our structured API's.

Yep, that's a good point. That list of settings we'll support for our first deliverable in March is shaping up nicely here in the wiki:


>> * Extend this to support multiple preferences in a JSON-based payload--making both the REST resource and the underlying gsettings/Node.js bridge handle a collection of settings
> At what point does the translation between canonical/universal settings to platform specific settings occur? So I assume the 'settings' the user has stored in a CouchDB instance are the same for any platform, Win32, OS X, Linux, and then we'd have some sort of translation mapping for each platform.  So the gsettings/Node.js bridge would likely take the already translated instance of settings so they map to Gnome/whatever applications.  Or would the gsettings/Node.js bridge be expected to take the universal settings and do the translation?

Yura and I were just chatting about that this morning. The settings handlers should deal with pre-transformed payloads--in other words, they'll get JSON data that represents the concrete, application-specific settings that user needs. Transformation from generic user preference to application-specific setting will happen upstream, either in the match maker or a companion component if necessary.

> Also, how do we anticipate that this entire thing shows up on the host gnome computer? Is it installed via a package manager, and then whenever you log in to Gnome the GPII node app just starts up on some local port?

I think that's a reasonable approach to take, yes. Once we have this up and running reasonably well, we'll create packages for key distributions. We'll get Avtar, our ops developer, to help with automation and daily builds of things like packages.

> * Look at implementing equivalents on Windows and Mac OS X, just to illustrate how cross-platform this solution is, with minimal dependence on native code
>> 	- I can take a look at the Mac implementation, even though it's not direct deliverable for Cloud4all
>> 	- Perhaps Trifon or Boyan might be willing to prototype the Windows equivalent once we've settled on a reasonable API?
> Cool.  Did we ever figure out any more about what the OS X equivalent of gsettings or the windows registry is?

Yep. The Mac provides an API for "user defaults," in the form of:

1. A command line utility
2. A C-level APi
3. An object-oriented Objective-C API plus an NSNotificationCenter notification (for cross-process events)

Here's the documentation:


Most Mac apps use the NSUserDefaults class, but I've noticed that few of them seem to bother to listen for the NSUserDefaultsDidChangeNotification (I know Antranig will love that event name!) and update themselves dynamically. This seems also to be the case for many Windows applications (including, apparently, Microsoft's own).

> Do we have a page that says which actual screen magnifier and reader we support? Then I can start looking at what they already store in gsettings.

Yep, it's in the wiki, above.

>> * Put together the equivalent list of generic AccessForAll preferences for the above use case
> Would this essentially be the universal version of the above?  Preferences still are for a screen reader and magnifier, except they are generalized out to *any* screen reader and magnifier, not specific to the gnome apps we choose?

Yes, that's right. In short, there will be three layers of preferences:

1. Generic, fully standardized user preferences: today, these are reflected by the ontology standardized in ISO 24751
2. Faster-moving, community settings: as we're developing, when we see common patterns of settings across a category of ATs, we'll put them in here and then work with the standards groups to solidify and elevate them to #1
3. Application-specific settings: these are the settings that are so specific to a particular application that we wouldn't want to promote them to #2 or #1. Off the top of my head, this might include things like toolbar settings, application-specific state, etc. Settings that you'd want to preserve when moving from one instance of the same application to another, but that really don't have any meaning outside of that particular app.

>> Yura is away in Berkeley this week, but I gather he's started to sketch out a Node-based preferences server with Express and CouchDB as a prototype. I think we're getting quite close to the point where we can write the matching code to transform user preferences into application settings and actually show the architecture working end-to-end in its simplest form.
> Awesome.

Here's the Git repo he's been working in:



Colin Clark
Technical Lead, Fluid Project

More information about the Architecture mailing list