On Mon, May 14 2018 at 13:16:02 +1000, William Brown <william@xxxxxxxxxxxxxxxx> 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. > > 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
