Re: LDAP backend

[Havoc Pennington <hp redhat com>]

monkeyiq dingoblue net au writes:
> hi,
> 
>     I am having trouble using gconf_value_new_pair_from_string().
> and also the list finction. At first I though it was just me (always a
> good start), but then I made a GConfValue using two existing
> GConfValues,
> this works ok, and I save it ok, but I can not read it again.
> 
>

I think we need to sort out the value serialization issue. We have
backends/val-encode.c, gconf_value_encode()/gconf_value_decode() in
gconf-internals.c, and the from_string() things.

The from_string() functions are intended to be heuristic parsers for
parsing user input on the gconftool command line; I'm not sure they're
quite right for a backend, where you probably want something more
space-efficient.
 
> If anyone else can reproduce this bug then I'll prolly look at
> gconf_value_new_pair_from_string()
> and see if I can find a bug in it.
>

Start by getting a backtrace in gdb, it might be somehting obvious.
 
> I also don't know if it makes sense to have
>   ldap_gconf_readable,    // not done (always 1)
>   ldap_gconf_writable,    // not done (always 1)
> 
> for ldap, does it make sense to do network IO and read a value to make
> sure that
> it can be done? I guess it is cached so a later read will need no netIO,
> but the
> writeable one is a tad harder, unless I find another API for it I may
> have to
> read it and then set it to something to make sure I can write to it...
> and it gets
> worse, if the API does not set values to existing values then I have to
> change it
> and then change it back again. 2x network IO.
> 

It's important to aggressively minimize network round trips. I would
definitely employ some kind of caching.

Havoc