> On 14 May 2018, at 18:26, Viktor Ashirov <vashi...@redhat.com> wrote: > >> On Mon, May 14 2018 at 13:16:02 +1000, William Brown >> <will...@blackhats.net.au> wrote: >>> On Fri, 2018-05-11 at 09:41 +0200, Simon Pichugin wrote: >>> 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. >> >> The issue is that if we want to use python-ldap, we wouldn't have >> lib389. We'd just use raw ldap all over the place .... >> >>> >>> 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 >> >>> 1. I think it is okay to use instance.add_s and instance.modify_s >>> for simple operations. >> >> The issue here is that Entry() isn't py3 safe. It also really limits >> what we can do, and the whole "dirsrv is a subclass of >> simpleldapobject" and intercepts operations to create Entry is just >> complex. >> >>> 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. >> >> >> The point of DSLdapObject is to: >> >> * capture knowledge of administration to an accessible api >> * To make a bridge between py2/3 >> * to give a higher level abstraction that "raw ldap" (which is frankly >> unusable) >> * to allow the elimination of Entry() and the DirSrv subclassing of >> simple ldap object. >> >> So everytime you find your self writing ".add_s()" or ".modify_s()", >> it's REALLY LIKELY that an adminsitrator needs to do this too! > It's not just about CLI tools. Please don't forget about tests. There we > need fine-grained access to LDAP primitives to write correct > reproducers. High level abstractions can stand in a way and do not > *exactly* do what is required.
The high level abstraction is not that high level once you look at it. There are plenty of ways to do low level actions though the dsldapobjects api, it’s meant to be able to test everything and retain that control. Regardless if you arent comfortable with that, then use python ldap directly. Entry in lib 389 is a bad abstraction that causes more issues than it solves, and should be removed. >> >> And although it's more work to encapsulate this to dsldapobject, it >> means we have implemented it once and can re-use it - and the jump from >> dsldapobject to a cli tool is very very short. It also makes the new >> webui easier because that will need to access all those apis too! >> >> There is much more vision here in this api then maybe I let on. It's a >> much bigger scope than some convinence functions, it's actually a >> gateway to ldap administration to eliminate the unusability of ldap. >> >> Of course, given my history with lib389, I would strongly advise us to >> follow options 2 or 3. I'm also happy to write up and knowledge >> transfer anything needed for the team. (And I apologise deeply for my >> recent abscence on mailing lists, I was traveling, and needed some time >> off). >> >> Thanks, >> >> William, >> >> _______________________________________________ >> 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
