Re: lib389 usage cheatsheet

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

[Index of Archives]     [Fedora Directory Announce]     [Fedora Users]     [Older Fedora Users Mail]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Review]     [Fedora Art]     [Fedora Music]     [Fedora Packaging]     [CentOS]     [Fedora SELinux]     [Big List of Linux Books]     [KDE Users]     [Fedora Art]     [Fedora Docs]

  Powered by Linux