Re: backends (ldap)

[monkeyiq dingoblue net au]

Havoc Pennington wrote:

> monkeyiq dingoblue net au writes:
> >     I am toying with some LDAP code making a backend for gconf.
> >
>
> Cool!

yeh, LDAP rocks, and having it as an option in gconf as a backend would
basically mean that all gnome apps would really want to use gconf...
(although some apps could use ini/db? themself it would be a major
pain for them to use LDAP themself).

>
>
> > I have decided to write it in C++ because C is very bad at string
> > handling etc.
>
> I think C++ mixed with C in dynamic modules is just asking for pain. C
> string handling isn't so bad, using the GLib utility stuff and
> GString. gchar* does implement the same iterator/container features as
> vector<T> you know. ;-)

Hmm, while I realise that Glib is a huge step in the right direction, being
able
to use the string manip that you are most used to does help out alot.
The other reason that I am/was looking at C++ was for the LDAP API.
the one in the RFCs that most impls follow is very memory management
intense. There seems to be no C++ wrapper though, which could use
references to ease the pain. I am now looking at gcj and jndi (which has
LDAP along with a bunch of other directory protos
http://www.javasoft.com/products/jndi/index.html

I still haven't ruled out C++, but it seems overkill to have to wrap LDAP C
in order to use it (which I would have to partly do implicitly anyway).

>
>
> > Nov 11 03:03:53 kloof gconfd (ben-32522): Failed to load source
> > `ldap:readwrite:/home/ben/.gconf': Failed:  Error opening module `ldap':
> > undefined symbol: cerr
>
> If you use C++, please don't use iostreams. I am opposed to iostreams
> in GConf because they cause mess when mixed with stdio and they don't
> lend themselves to internationalization.

I might use string ones, but as you later point out cin, cerr, cout are not
usable
in gconf.

> meaning to mail Colm) you need to use gconf_log(), don't write to
> stderr with fprintf() or cerr. Remember this is a daemon.

yeh, using gconf_log() now, and the trimmed down C modules is getting loaded.
:-)

>
> Anyhow, the problem is simply that the global variable 'cerr' is in
> libstdc++, which is not loaded. In principle this means you would add
> libstdc++ to the LIBADD line in the Makefile.am to make it a
> dependency for the module. However I have no real idea whether there's
> a portable way to do this or a portable name for the standard C++
> library.

hmm, I could just do it in plain C, but to lookup data is quite a pain.
Basically the C API is so tedious to use that I'd never plain to use it
again, whereas I might use the exp again if I did it in C++ or Java.

Coding is stopped at the moment, looking at JNDI and looking
for a decent C++ wrapper (openldap mailing list hints to SuSe
having made one, so there is hope yet).

How badly does the idea of using Java mesh with the whole gconf
project ?