Re: backends (ldap)

[Rodrigo Moya <rodrigo linuxave net>]

monkeyiq dingoblue net au wrote:

> 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 ?

Hi!

I don't know if you've heard about openldap implementation. It is in C, 
and although I don't know it very very well,
it seems quite easy to use. I think you can download from 
www.openldap.org, and if not, RedHat includes it, and
in Debian, it's the package named libopenldap*


I'm not the GConf maintainer, so I can't vote on this, but I won't 
suggest at all using Java for this GConf backend.

cheers