Re: backends (ldap)

[Havoc Pennington <hp redhat com>]

monkeyiq dingoblue net au writes: 
> 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();
> }
>

I would not expect that to compile. _Maybe_ on Red Hat 7.0, not on any
other distribution. libstdc++-v2 is simply broken, and libstdc++-v3
which implements this isn't widely deployed.

It's also broken code for the same reason iostreams code is usually
broken - you can't put '<< " LDAP error code:" << err <<  ". LDAP error string:" <<
> ldap_err2string(err);' into a message catalog. printf()-type formats are
far better here. So i18n libraries such as IBM's have to come with an
alternative to iostreams.

You can hack an internationalizable format-type thing on top of
iostreams, Karl Nelson was fooling with that, but basically the whole
streams concept breaks message catalogs, which are the only sane way I
know of to do i18n, which makes iostreams close to useless for any
user-visible text.
 
> it uses libgcj...
> http://sources.redhat.com/java/faq.html#1_7
>

I'm aware of that, my question is how well will libgcj work inside a
dynamically loaded module when the Java runtime isn't controlling the
process. Maybe it will work fine, but I sort of doubt it.

You can't require gcj anyhow for something in the GConf distribution,
it shouldn't require gcc to build.
 
> 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..."
> 

I would strongly discourage C++ if this module is for inclusion with
GConf; it causes problems and I see no benefit.

Havoc