Re: LDAP backend

[Colm Smyth <Colm Smyth ireland sun com>]

>From: monkeyiq dingoblue net au
> ...
>
>    I am having trouble using gconf_value_new_pair_from_string().

This isn't a reliable function for constructing a pair; the
functions in backends/val-encode.c are intended for just
this purpose. They're currently without documentation and
could have better names; I plan to create and check-in
some changes, which will include some improvements
that should make the val-encode API's easier to use for
serializing and de-serializing GConfValue's in other
backends. If you look at bdb*.c, you can see where the
current main API's are used (bdb_serialize_value,
bdb_restore_value and _gconf_check_free); these will
become _gconf_serialize_value, _gconf_restore_value and
_gconf_free_serialized_value respectively.

Colm.

>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.
>
>--- deep in the reading function()
>
>  car_type = _ldap_gconf_get_value( ld, err, entry, "cartype");
>  cdr_type = _ldap_gconf_get_value( ld, err, entry, "cdrtype");
>  gconf_log( GCL_DEBUG, "ldap_gconf_reify_gvalue create a pair");
>  gconf_log( GCL_DEBUG, "ldap_gconf_reify_gvalue create a pair
>car:%s",car_type); // == string
>  gconf_log( GCL_DEBUG, "ldap_gconf_reify_gvalue create a pair
>cdr:%s",cdr_type); // == string
>  gconf_log( GCL_DEBUG, "ldap_gconf_reify_gvalue create a pair
>value:%s",value); // == (left,right) -- I think
>
>  if( !car_type || !cdr_type ) {
>   return NULL;
>  }
>
>  retval = gconf_value_new_pair_from_string( // -- segv.
>    gconf_value_type_from_string(car_type),
>    gconf_value_type_from_string(cdr_type),
>    value,
>    err);
>
>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.
>
>
>BTW  the only two methods that remain are:
>  ldap_gconf_query_metainfo,
>  ldap_gconf_set_schema,
>
>which should be easy compared to  ldap_gconf_remove_dir() which I did
>last nite.
>(LDAP and recursive delete, hmm chicken).
>
>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.
>
>
>There are a few mem leaks still, but they are mostly noted with
>FIXME already,
>so it should be done soon.