Preference namespaces

Jon Parise jon@csh.rit.edu
Tue, 20 Feb 2001 00:32:14 -0500


I just started doing some preliminary work on the new preference
namespaces and ran into some considerations that I'd like to raise
before the group.  I welcome input from all directions.

First off, every application has its own namespace (eg. 'imp',
'kronolith', etc.).  There is also a "global" namespace which is
identified by an empty namespace string (so, by default, all
preferences are "global" unless marked otherwise).

I'll illustrate this structure in SQL terms:

                 Table "horde_prefs"
     Attribute  |   Type   |      Modifier       
    ------------+----------+---------------------
     uid        | char(32) | not null
     namespace  | char(16) | not null default ''
     pref_name  | char(32) | not null
     pref_value | text     |

The basic infrastructure is pretty much done now, and I have things
mostly working, assuming you want all of IMP's preferences to be
marked as IMP-specific (ie. 'namespace' = 'imp').

However, we want to allow for a mix of "global" and application-
specific preferences.  It looks like the only sane way to enforce
those settings is by adding a new attribute to each preference defined
in config/prefs.php.  An entry would then look like this, in the case
of a "local" preference:

    $_prefs['save_sent_mail'] = array('value' => 1,
                                      'changeable' => true,
                                      'shared' => false,
                                      'type' => 'checkbox',
                                      'desc' => _("Save sent mail"));

Or in the case of a "global" (or shared) preference:

    $_prefs['language'] = array('value' => 'en',
                                'changeable' => false,
                                'shared' => true,
                                'type' => 'select');

Hopefully, this is making sense so far.  I think this will result in a
fairly clear and flexible implementation, allowing site administrators
to arrange their users' preferences as they prefer.

So, aside from implementing the above login (which shouldn't be too
bad, really), I ran into another question.  We now have a notion of
scope (should I be using the term 'scope' instead of 'namespace',
btw?).  I think it would make more sense for the "local" values to
override the "global" values, should we get two results for 'language'
or 'full_name'.  Does that make sense, too?

Also, if any of you see anything major that I might have missed,
please point them out.  This is really something I'd like to
implement correctly the first time through. =)

-- 
Jon Parise (jon@csh.rit.edu)  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member