Hi Thierry, I agree with you, it was exactly my proposition :) Keeping main python-ldap elements is important because we don't want to implement or mask/wrap this basic functionality (like working with controls, etc) we just want to redirect them.
Ideally, we should make our admin library very intuitive for the people who already knows python-ldap and just LDAP concepts. I will continue adding more information to the docs regarding DSLdapObject and I'll try to make it a bit closer to LDAP concepts (at least in wording), I already have something in mind. Thanks, Simon On Wed, May 09, 2018 at 06:12:33PM +0200, thierry bordaz wrote: > Hi Simon, > > Thanks Simon starting this thread :) > Currently lib389 is mostly used by ldap devel/QE and seems realistic > to become the admin library (for example used by freeipa or others) > and component of 389 administrative tools. LDAP knowledge is a > requirement for all of them. In that sense, lib389 should continue > to follow/offer basic LDAP elements (connections, naming_ctx, > req/resp, synchronous/asynchronous, extop, control...). > I agree that those elements are a bit frustrating for people wanting > to use LDAP as a simple repository. The DSLdapObject abrstaction > looks very promising. It can be oriented to simple use case: create > users and groups, manage memberships, authentication/rights, > automatic deployement on several replicated instances. Then extended > on demand. > In short, IMHO I would prefer to keep the most of the LDAP elements > (option 1) and propose/extend easy POC interface (option 2). I am > not sure the work DSLdapObject is my favorite, we could name it > according to the use case we want to propose. > For me option 3 will be the worse option. I remember an abstraction > layer that had a so high level that I constantly looked at the > access/error log, to be sure that the program was doing what I was > thinking it should. > best regards > thierry > _______________________________________________ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
