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


On 05/09/2018 04:56 PM, Simon Pichugin wrote:
Hi team,
recently, we had a discussion on a scrum meeting about lib389 and its new API.

If I understood right there was an opinion that lib389 DSLdapObjects API
is not very intuitive and it is much easier stick to python-ldap style
because it uses ldapmodify/ldapadd wording (or close enough to it).
And I partially agree with it (and I already have some thoughts how we can
improve it).

Many patches on the review show that the people don't change their code
to the new way.
I've given some thought to it and this is what I came up with:

1. I think it is okay to use instance.add_s and instance.modify_s
    for simple operations.
2. If you'd like to make your life easier, you can use DSLdapObjects API
    (and I'll help you with that)
3. We should stop using old lib389 API because we don't support it anymore
    and it will be depricated in the future. We should use DSLdapObject
    instead and we should improve it if we don't like something about it.

We have a lot of docstrings written in lib389 code and the code itself
is pretty readable, in my opinion. But I'd like to make the life easier
and I've started to write 'lib389 cheatsheet'. It has old way/new way
comparison blocks and I base it on the real-life code from your patches
adding some commentairies.

For now, it is here:
https://fedorapeople.org/~spichugi/html/cheatsheet.html

Thanks!
Simon
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Reply via email to