[Architecture] gsettings prototyping
swgithen at mtu.edu
Wed Feb 8 02:53:06 UTC 2012
One of my personal next steps that I'll be working on largely includes
cleaning up the bindings and fixing things so they're not so slipshod.
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.
More comments inline. Also, if any of my comments/questions are already
answered on a wiki page or document somewhere just let me know. :)
On 02/06/2012 06:42 PM, Colin Clark wrote:
> This is exceptional! I watched the screencast and spent some time with the code. Nice work. This is a great start on the process of building a RESTful binding to the platform's central settings store. What do you think the next steps are?
> Off the top of my head, it seems like we might want to do a few things:
> * 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?
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?
> * 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?
> * Put together a handful of real preferences we'd like to support for our first two use cases: auto configuration of a screen magnifier and a screen reader
+1 +1 +1
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.
> * 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?
> 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.
> As always, I'm a bit behind on documenting this whole approach in our wiki; that's my main goal for this week.
> Again, I'm really impressed by this work, Steve!
Thanks! This is fun stuff to work on! :)
> On 2012-02-05, at 12:54 PM, Steven Githens wrote:
>> Hi all,
>> In addition to going back and catching up on the threads with the architecture and payload examples, I finished my first set of prototypes to get up to speed on stack, mostly for gsettings and node extensions.
>> It's essentially writing/reading from a custom gsettings schema from dconf-editor, a C and a Python GTK+ app, and a one page node.js express app using a custom C extension to call the gsettings api.
>> I cut every corner possible to get the whole thing working as fast as possible, but I did write the node.js C extension from scratch, and the environment actually has a pretty nice build toolchain I think.
>> Architecture mailing list
>> Architecture at lists.gpii.net
> Colin Clark
> Technical Lead, Fluid Project
More information about the Architecture