<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hello Roberto,<br>
      <br>
      <blockquote>Thanks, I also wish you an happy new year and you
        recover well. It is great to talk to you again <span
          class="moz-smiley-s1"><span> :-) </span></span>.<br>
        <br>
        I am quite novice with python and my first approach was to use
        it as a real object oriented language, having instances of
        everything (suffix, MT, replica, indexes...). Then discussing
        with Jan and looking at your implementation of dsadmin, I
        realized that it is a common use to wrap methods of class and
        rather use python as a functional language (e.g.
        self.backend.setProperties(...) rather than 'backend=Backend();
        backend.setProperties(..) ')<br>
        The big advantage I see in functional approach is that the
        'object' are no long python objects but the configuration object
        stored in 'cn=config'. So it prevents the problem of
        synchronizing the python object with the 'cn=config' object. So
        the only remaining object is the DS instance (dirsrv/dsadmin)
        and methods to access its config.<br>
        <br>
        Does it prevent to use fake directory ? I am not enough familiar
        with fakeldap, would you give me an example of why the current
        implement would not work with fakeldap ? <br>
        <br>
        About the shift of parameters to dictionary I think both
        approaches are valid. Just let me explain why I choose
        dictionary, it comes from what could be future CLI.<br>
        for example we may have a CLI pattern like:<br>
        <br>
        &lt;admin_cmd&gt; &lt;verb-resource&gt; [parameters] [options]<br>
        <br>
        admin_cmd::= "dsadmin"<br>
        verb-resource::= &lt;verb-suffix&gt; | &lt;verb-replication&gt;
        | &lt;verb-backend&gt; |...<br>
        &lt;verb-suffix&gt; ::= list-suffix | create-suffix |
        delete-suffix...<br>
        parameter::= &lt;parameters to connect to the DS instance (port,
        credential..)&gt;<br>
        options::= &lt;option to process the command and also some
        properties&gt;<br>
        <br>
        Then we have specific &lt;verb-resource&gt; to define the
        resource properties (entry cache size, directory path, type of
        replica...)<br>
        <br>
        They are set-suffix-prop, set-backend-prop...<br>
        Basically once the resource has been created (with some
        properties), any 'properties' of the resource can be read/write
        by set/get-&lt;resource&gt;-prop.<br>
        <br>
        So for the CLI (or other admin application) we need to send
        prop:value to an instance. prop are then available in an include
        file, but in a human-readable way (like 'suffix') rather than in
        an attribute way (like 'nsds5replicaroot'). I used a dictionary
        to pass the properties (rather than functions arguments) mainly
        because some resource may have many properties, also because all
        the set-&lt;resource&gt;-prop function have a similar interface.<br>
        <br>
        I do not know if I answer correctly your concerns. Just let me
        know if I missed your questions.<br>
        <br>
        regards<br>
        thierry<br>
      </blockquote>
      On 01/03/2014 01:10 PM, Roberto Polli wrote:<br>
    </div>
    <blockquote cite="mid:1413407.ID6tN0Ghr8@rpolli" type="cite">
      <pre wrap="">Hi Everybody!

First of all Happy New Year, hope it will be filled of fun!

I am really sorry for not supporting you for so long, but as I told you I 
can't still spend too much extra-work time coding :(.

I saw the evolution of the library and I'm glad of the new functionalities and 
the split-up of the brooker in various files. 

On the other hand I think that the new interface changes don't go on the 
simplicity/usability path, so I'd like to understand your targets and give 
some suggestions.

On Thursday 12 December 2013 21:58:12 thierry bordaz wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Ticket <a class="moz-txt-link-freetext" href="https://fedorahosted.org/389/ticket/47625">https://fedorahosted.org/389/ticket/47625</a> changes the interface
of DirSrv.
This ticket is the porting side of the test cases to the new interface
</pre>
      </blockquote>
      <pre wrap="">
1- The new interface initialization is substantially different from a standard 
client-server interface. A user expects to instantiate objects like this:
 # client =  Telnet(host, port, credential)

2- This is quite the behavior of the LDAPObject superclass, which I would like 
to retain so that we can use fakeldaps for unittest

3-  The standard DirSrv.__init__ (and the same is valid for other methods), 
containing a set of parameters is intrinsically documented. Shifting core 
parameters in dictionaries:
 a- de-documents parameters and default values outside the method signature;
 b- requires parsing and setting of default values;
 Python allows to retain the dict-style stuff using the **magic, which I would 
embrace in this case.

The new Interface Layer would be easily implemented in a subclass.

Let me know + Peace (and sorry again for my absence),
R. 

</pre>
      <blockquote type="cite">
        <pre wrap="">
<a class="moz-txt-link-freetext" href="https://fedorahosted.org/389/attachment/ticket/47628/0001-Ticket-47628-port">https://fedorahosted.org/389/attachment/ticket/47628/0001-Ticket-47628-port</a>-&gt; testcases-to-new-DirSrv-interface.patch
</pre>
      </blockquote>
      <pre wrap="">
</pre>
    </blockquote>
    <br>
  </body>
</html>