Re: ASN.1/DER compiler

["Kurt D. Zeilenga" <kurt@boolean.net>]

I suggest that questions specific to development of custom OpenLDAP
backends be moved to OpenLDAP-devel.

I'll try to keep this response fairly implementation neutral.

At 08:44 AM 12/1/99 +0100, Mikael wrote:
>This is great news for us, we need to configure OpenLDAP version that work with/on:

Note that I was making a general point that one should not reinvent
wheels unnecessarily.  I do not mean to imply that OpenLDAP wheel
is the right wheel for your road.  However, OpenLDAP isn't the only
wheel.  Most LDAP SDKs provide LBER libraries to which you can use
to implement servers... and many servers implementations provide
plugin architecture to allow you to replace or augment the
internals of the server.  In particular, the plugins APIs allow
you to provide alternative mechanims for store and retrieve entry
data.

>    *    NT4 platform

OpenLDAP full port to NT is still under development.  In particular,
SLAPD has been ported but not fully tested.  Though development
code, you are likely better off starting with it than trying to
reinvent the whole.

Of course, many LDAP vendors provide robust plugin APIs (and
support NT) today.  You may want to consider going with one of
these fine products.

As noted above, you can implement your own server (though I don't
recommend it) use an existing LBER library.  For NT and LDAPv3, I
would suggest using the Mozilla SDK.
  
>    *    ldapv3 protocol

OpenLDAP LDAPv3 support is under development.  Most LDAP vendors
are shipping v3 today.

>    *    which 'delivers' the actual client request in
>this backend mechanism for further calling of DCOMM functions.

Most servers derived from U-Mich LDAP (such as OpenLDAP) provide
such mechanism.  Netscape has a robust plugin API and is shipping
for NT.  Other vendors likely offer similiar plugin APIs.

>1.    what version of OpenLDAP should we use?

I generally recommend using OpenLDAP 1.2.  However, its SLAPD
is ported to NT nor does it support LDAPv3.   Considering you were
hot on implementing your own server, I suggest you experiement
with our devel code.  In particular, you might experiment with
our TCL and Perl backends (not sure if they support NT yet).
However, I do NOT recommend deploying 'devel' code.  Hence, you
might want to experiment with vendor's products to provide the
LDAP server frontend.

>2.    where can I find documentation of this backend mechanism(preferable with
>examples)?

Well, for 1.2, the U-Mich Guide covers the basic backend mechanims
and the OpenLDAP distribution contains an number of examples.  Devel
docs have yet to be written (though we've updated all examples
backends).

LDAP vendors provide documentation and examples for their plugin
APIs.

>But where does OpenLDAP store the directory structure information?

OpenLDAP relies on 'backends' to store the directory information.
Each backend uses its own mechanism, hence there is no one answer
to your question except 'OpenLDAP relies on backends to store
directory information.'  You can add your own mechanism
by implementing a custom 'backend'.

>The Btrieve database is 'flat' and we have multiple search functions for it but the
>is not directory information.

Many (most) of the backends currently supported use
'flat' databases.  I would think one could implement
an LDBM wrapper for Btreive.  However, for your problem
(exposing existing information in a remote database), requires
a custom solution.  You might be able to use a scripting
backend (like back-perl/back-tcl), but you likely will need
to write your own.

Kurt

----
Kurt D. Zeilenga		<kurt@boolean.net>
Net Boolean Incorporated	<http://www.boolean.net/>