[Tfug] GConf and it's ilk

Bexley Hall bexley401 at yahoo.com
Wed May 28 11:18:12 MST 2008


Hi, John,

[has it stopped raining, yet?  :> ]

--- John Gruenenfelder <johng at as.arizona.edu> wrote:

> On Mon, May 26, 2008 at 03:17:39PM -0700, Bexley
> Hall wrote:
> >
> >My main reason for doing this is to make it easier
> >for a user to configure an appication (or the
> >system itself).  Each configurable entity can
> >just export a form that presents all of the
> >configurable options and let the user make
> >adjustments at will.  (of course, the form isn't
> >static as it must enforce application-specific
> >semantics, etc. -- but, all of that becomes
> >visible to the user in a very obvious manner!)
> 
> To the best of my knowledge, there is no system as
> robust as the one you
> specify, especially in the area of "permissions". 
> Of course, I'm not really
> sure how you would handle that except by having apps
> agree to be truthful and
> not stomp each others settings.

Give each application an (unique) identifier.  This
can be done when the application is "registered"
(i.e. installed) with the system.

When accessing the configuration database, that
credential is provided.  Database enforces any
permissions based on the design of the structures
(tables, etc.) that any particular application
has created for itself.  I.e., if I don't want
another application dicking with my "date format"
setting, I make it read-only to those apps -- they
can *see* it and, presumably, adjust their 
presentations of dates to correspond with my
expressed preference (e.g., perhaps "I" am the
"system" application) but only *I* can alter it
(by the user invoking *my* configuration panel
under my supevision -- so I can make sure any
*other* related changes are made/enforced at
that time)

> >The biggest down-side, IMO, to this is the
> >performance issue (space & time).  But, I think
> >I can afford both (I consider this a far better
> >use of resources than "pretty wallpaper" and
> >"animated icons"  :> ).
> 
> I think this is a non-issue.  If done poorly (see
> Windows' registry), then
> even a binary format can kill performance.  But *NIX
> has done well for decades
> using plain text configuration files for almost 99%
> of everything.  The time
> it takes to process and update is inconsequential,
> even more so these days with supercomputer
> cellphones.

Well, my point was acessing "objects" through a
database is probably more expensive than accessing
them directly from a file system.  :-/  Just the
API itself has more overhead.

But, as you say, it's not the sort of thing that
your application would be doing inside a tight
loop (e.g.)!  Knowing that is how you access
this information, you would no doubt craft your
applications to pull down that information when
needed and cache it locally (or, defer until the
last possible moment)
 
> The bigger time issue is the time it takes to write
> such a system correctly.
> With any text format that users can potentially edit
> you'll need to be more
> robust about error checking.  Checking doesn't take
> time, but writing the code
> to do the checking right will.

Yes.  But, you can also rely more heavily on
multiple-choice fields.  (Surprisingly, most
configuration seems to fit this form!)  And,
you can then just define a list of valid choices
(i.e., TBL_DATE_FORMAT_CHOICES) and let the
DBMS enforce it for you.  Makes it nice as user
can *see* what the valid choices are a priori.
By contrast, most (well written) UN*X apps *enforce*
those choices but the only way for the user to
*see* them is to read the man page (assuming it
is kept up to date!) or parse the sources.

> >Any other issues that have come up with people
> >using things like GConf?  Or, is it too "impure"
> >to fit my goals??
> 
> gconf certainly meets some of your goals, but
> probably not enough.  And I
> imagine it would be more trouble than it's worth to
> modify gconf to suit your
> needs... but that's just a guess.

How does it fare with dynamic updates (e.g., changing
a setting that two or more apps use *while* those
apps are "open")?  Does this *confuse* the user
or is it a "nice feature"??

Thanks!
--don



      




More information about the tfug mailing list