Re: backends (ldap)

[monkeyiq dingoblue net au]

Havoc Pennington wrote:

> monkeyiq dingoblue net au writes:
> > I might use string ones,
>
> Be careful, string streams are not portable (and importantly don't
> work on most current Linux distributions).

Yeh, I hadn't really thought of that, sort of a catch22, need to checkout

what compiler comes with each distro and then if each of these compiler
(versions)
support STL ok. what a pain.

What do you mean by "not portable"... I am only planning on doing
something like:

const char* make_ldap_error_string( LDAPSource* xs,  LDAPMessage
*res) {

 ostrstream oss;
 static string s;
 int err = ldap_result2error(xs->ld, res, 1);

 oss << " LDAP error code:" << err <<  ". LDAP error string:" <<
ldap_err2string(err);
 s = oss.str();
 return s.c_str();
}

>
>
> > How badly does the idea of using Java mesh with the whole gconf
> > project ?
> >
>
> I think Java introduces even more deployment and linking problems than
> C++. I'm not at all sure how a dynamically-loaded module can use a
> Java runtime while the main process isn't - how would the garbage
> collector work?

it uses libgcj...
http://sources.redhat.com/java/faq.html#1_7

>
>
> You are going to have to deal with lots of fun C memory management
> anyhow, due to the interface between the backend and the main GConf
> process, so I'm not sure C++ or Java are going to get you anywhere.

I think C++ would be nice, and not that hard to use here, java would
possibly be a ripe pain to use here, and might even get me flamed for
even doing it (ironic situation indeed).

I am just looking around at other possibilities first, so that I make the

choice based on fact rather than "there is a C interface, great where
is vim..."