Re: hardcoded values in ~/.gconf

[Joerg Barfurth <joerg barfurth sun com>]

Hi,

Jody Goldberg wrote:
> > On Wed, Jun 04, 2003 at 09:13:41PM -0400, Jody Goldberg wrote: 
> >
> > > If this is going to be solved I'd like to see something a smidge
> > > more powerful.  If hard coding HOME is an issue, the same will hold
> > > true for various other system dirs.

Very true.

Some applications use configurable 'profile' locations. Then there are 
system directories that vary between distros or OSs in heterogeneous 
environments. Next there is the install prefix of applications and 
components. This is compounded by the fact that the same stuff may be 
mounted into different locations on different machines.

Of course the problem is not new. And actually there are many existing 
approaches for this and similar problems out there from which we can borrow.

As I am pretty familiar with the approach used in OpenOffice.org and 
also had a short encouter with Mozilla preference services, I'll try to 
explain how they do it.

But we need to keep in mind that it ultimately is up to the applications 
to make this happen. Of course providing interfaces and services that 
make it easy to store file references as base-relative data is important 
to make this happen. But it is also necessary to spread consciousness of 
the necessity to make use of these services.


> > > eg in gnumeric it irks me that we end up storing paths like
> > >    /local/gnome22/test/lib/gnumeric/1.1.18/plugins/fn-info
> > >
> > > Where I'd rather be smarter and do something like
> > >    &gnumeric_libdir;plugins/fn-info

OpenOffice.org uses something like "$(insturl)/plugins"
Mozilla uses "[dirkey]path/to/file"

> > Proposed API for that? Maybe just
> > gconf_client_set_filename_munge_func()?

I am not sure this is the best approach. Some settings are (or could be) 
shared. That means they should also be processsed the same way. OTOH, if 
a standard filename munging function is made available as well that may 
be a non-issue. More on this below.


> I discussed this with markmc a few weeks back and wanted to get the
> resulting thoughts out to the list before they were lost.
>
> My initial plan had been to have a client register a set of
>     symbolic name -> path
> pairs.  Then introduce a new type, 'filename' that would check the
> supplied string for know prefixes and store it as
>     symbolicname:remainder
>
> Mark prefered not to push this complexity out to the backends and
> suggested apps use the simpler
>     set_string (client, "$(symbolic)/remainder");
> and that gconf would provide a 'convenince hack for GConfClient' to
> read the results.

There are actually several parts to this:
1. How to obtain and manage a set of symbolic names and prefixes
2. How to identify a prefix to use when storing
3. How to encode prefix+relative path
4. How to support decoding and resolving when reading

If sharing of preferences is desirable, the symbol->path mapping should 
be available as a public service, that offers at least a core set of 
symbolic names to all clients.

In OpenOffice.org this is handled by a special component. (See 
http://api.openoffice.org/docs/common/ref/com/sun/star/util/PathSubstitution.html) 
In this service tere are some builtin variables. Additional variables 
can be defined in a special branch in the configuration database. This 
configuration data includes metadata that can be used to associate 
different values with different hosts, OSs or other selectors. Another 
way to provide special variable values for different contexts is to put 
them into an appropriate (e.g host-local) backend layer.

In Mozilla there is a service that handles mappings from keyword 
identifiers to special directories. AFAICT this is modeled after system 
services to locate 'special' places, as they exist e.g. in MAC OS and Win32.

For 2. I agree with Mark that it should be the client's responsibility 
to take care of identifying the relevant prefix. While there are some 
general strategies to identify the best prefix to apply given a list of 
mappings, there may be special cases where the standard method does not 
yield the desired prefix.

In OpenOffice.org the PathSubstitution service discussed above can be 
used to do a default decomposition, but clients with special needs can 
also do this manually.

In Mozilla I actually don't know the level of builtin support for 
identifying a key or prefix. The preference component is fed a special 
RelativeFilePref object, where the decomposition has already happened.

> <markmc>	anyway, I think we could come up with a sane encoding
> <markmc>	and the APIs would handle the escaping

That concerns mainly 3. With your example and the approaches of 
OpenOffice.org and Mozilla there are already three proposals.

One possible extension of this is to additionally include the last known 
value of the prefix. This enables clients (or client versions) that 
can't resolve the symbolic name to try the absolute path instead. Of 
course that still leave room for resolution failure (or, worse, 
resolution to a locally wrong location). One example where information 
for multiple relative and absolute resolution strategies was combined 
are MAC OS alias files/resources (sort of symbolic links that can follow 
a file that is moved).

For the last point there is a tradeoff between ease of use and cohesion 
(or separation of concerns). Of course having the functionality 
conveniently available at the configuration API has some advantages in 
that it probably entails higher awareness of the service and encourages 
use of this api for filename preferences. OTOH there may be uses of the 
mapping that are not directly tied to configuration (there are other 
places where pathes may be persisted). Supporting the ability to plug a 
standard mapping service into the configuration API may well be the best 
compromise here.

In OpenOffice.org this is fully separated. Decoding and resolving is 
done by the PathSubstitution service, which must be invoked by the 
client in a separate step after reading the raw preference data as a 
string. This also reflects the architectural positioning of those 
services: The PathSubstition service belongs to a higher-level 
abstraction layer than the raw configuration access services. This also 
prevents circularity problems, as the PathSubstition service relies on 
configuration data itself for variable definitions.

In Mozilla decoding and resolving is integrated into the preference API. 
If a client requests a RelativeFilePref object, the stored string will 
be parsed and resolved to a LocalFile object that is returned to the 
client. Other clients can of course use the directory key resolution 
service themselves, but they have to combine this with an additional 
relative path itself.

Just some thoughts.

Regards

Joerg

--
Joerg Barfurth
Software Engineer        mailto:joerg barfurth sun com
Desktop Software (Configuration Manager)
StarOffice Configuration http://util.openoffice.org
Sun Microsystems         http://wwws.sun.com/software/javadesktopsystem