[Date Prev][Date Next]
first of all; thank you for the rapid response.
"Kurt D. Zeilenga" wrote:
> At 12:55 PM 11/23/99 +0100, you wrote:
> >I have written a system that should handle incoming ldap strings (open,
> >bind, search e.t.c.)
> >and translate these into requests towards out (flat) Btrieve database.
> Might be easier to just write a custom backend to an existing
> LDAP server.
We have been looking for LDAPv3 servers that we could use but either
are VERY expensive or they dont support ldap version 3. The free ldap
servers also cannot use a flat database, they need berkley database or
other specific database as storage platform.
This is what I've heard so far.
Am I wrong about this?
The best would ofcourse be to implement a existing LDAPv3 server and
'attach' it to out database. But we cannot change database.
If you think that we could use OpenLDAP on NT4.0 and connect it to out
flat database (Btrieve) which contains all the leaves in the directory
then it would be great.
> The messages are encoded using
> a subset of ASN.1 Basic Encoding Rules. RSA provides a nice guide
> to ASN.1, BER, and DER at:
> >In what format are these incoming strings???
> The octet steam is a series of BER sequences.
Ok thanks, I need to read more about octet strings and BER seq.
> >Does these ldap string correspond to the ldap-URL syntax format (so I
> >can interpret them to real(?) requests)???
> >Greatful for any help!
> >PS! If any other developer are working with the same problem and would
> >like to cooperate then please contact me. DS!
> Very few developers work at the octet stream level when developing
> applications using protocols based upon ASN.1. There is very little
> reason to reimplement BER/DER.
I guess that we should look for a compiler for translation of incoming
tcp/ip 'strings' and convert them into ldapMessage structure.