Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2004-12-26 at 10:47, Volker Lendecke wrote:
> Hi, Samba4 developers!
> How much of the ldb API is set in stone?
> Half a year ago I did some work to get rid of the RFC API, and in samba4 =

> ldb API re-invents exactly the same API in a less functional varient. For
> example currently you can't get paged results through that API (my curren=

> favourite, but this should only display the point).
> libcli/ldap/ outlines a "new" api, based on structures. Would you be will=

ing to
> convert the existing code to that kind of API? This would essentially mea=

n to
> re-implement much of ldb_tdb.c and the modules stuff. This API gives us t=

> full LDAP semantics while already being talloc based. Sooner or later (I
> suspect rather soon...) we need more of the LDAP semantics than the curre=

nt ldb
> API provides anyway.
> I might start looking at that, but this is not worth the effort if Samba4=

> settle on that API.

I've never seen Samba4 settle on anything when somebody proposes (and
implements) something better :-). See how well we 'settled' on
old-style talloc, and so many other things.

I've found the ldb interfaces fairly easy to work with, for the 'single
result query' kind of question. However, that doesn't stop you keeping
that single interface 'intact' and fixing the rest. =20

Even if 'RFC' APIs are kept, there is a very good argument that LDAP
should be no different to CIFS in the client/server style, and further
that if ldb is so closely tied to LDAP (by the fact that we must back an
LDAP server onto to it) that it should supply a similar API modal.

Andrew Bartlett

Andrew Bartlett abartlet@samba.org
Authentication Developer, Samba Team http://samba.org
Student Network Administrator, Hawker College abartlet@hawkerc.net

Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBzi/Nz4A8Wyi0NrsRAp1TAJ4uh3vBeqCcnMRbGv1iv7Aqcotj7gCgh +8k