why bonobo-config

[Michael Meeks <michael ximian com>]

On 29 Aug 2001, Havoc Pennington wrote:
> If you have an abstraction for a given feature, you can chain them
> infinitely:

        Depends if the abstraction actualy maps a feature superset onto
the underlying (more limited) abstraction - as is the case with
bonobo-config and gconfd.

> However, only one of these layers is sufficient to let you magically
> plug a different backend later. i.e. there is no point having 6 layers
> of abstraction that are all basically parallel.

        Yes - true, but the real issue here is maintainership - and it
seems that it is not possible to get changes into GConf[1], that it's
design is strongly based on a premis that CORBA shouldn't be exposed -
which is antithetical to the GNOME viewpoint. Luckily we don't have 6
extra layers of abstraction, just 1.

	Consequently hiding the module and it's API allowing for its
(possible) replacement in future without code disruption seems a resonable
long term strategy for Gnome IMHO - quite apart from the added benefits
that bonobo-config gives you in terms of API reuse, scripting bindings,
rich types etc.

	So the abstraction is useful for many technical reasons, but also
for pragmatic reasons.

        Regards,

                Michael.


[1] - ok so again, people need to trawl the mail archives to see the
attempts to write bonobo-config as part of gconf, and to work with Havoc
etc.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot