Re: The technical rationale

[Seth Nickell <snickell stanford edu>]

> Do we really need to support more backends on the wrapper level? I think
> it'd make more sense to put all the pluggable backends thing into GConf
> and force the bonobo wrapper to use it -- that way, when a new backend
> comes out, GConf-only applications can take advantage of it as well.

Basically the issues here is...

Is it more useful for the application programmer to choose the storage
backend or the "system administrator / distribution / end user" (though
I'm guessing most home users won't care at all).

The benefits to the application programmer making the choice seem to be
his/her ability to choose a config system that best fits their
particular data. One disadvantage is that we will have to ensure that
the application programmer's choice of backend is present on the system.

The benefits of the "end user" making the choice are the ability to have
a maleable system even if you are not a programmer and to store data in
a variety of mechanisms through editing a single config file (e.g.,
LDAP, berkeley db, etc). The disadvantage is the application may not
know how its data is stored and so the data may not perfectly fit the
storage mechanism.

I'm inclined to say that the latter (making it flexible for the
end-user) is *FAR* more important and that the former will only be a
source of headaches. The monikers are cute in this situation, but the
"flexibility" here may come at the cost of important flexibility at
runtime. I personally look forward to a world where I can walk around
with my wireless device and access all my GNOME settings through GConf
transparently stored on an LDAP server "who knows where". Can you
imagine how cool it would be if we could setup systems so you just type
your username, password, and home server and GNOME logs in with all your
settings? To me, that is more of an investment in the future, the future
of our users, than trying to foist component systems on application
programmers.

-Seth