Hello Roberto,

Thanks, I also wish you an happy new year and you recover well. It is great to talk to you again :-) .

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(..) ')
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.

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 ?

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.
for example we may have a CLI pattern like:

<admin_cmd> <verb-resource> [parameters] [options]

admin_cmd::= "dsadmin"
verb-resource::= <verb-suffix> | <verb-replication> | <verb-backend> |...
<verb-suffix> ::= list-suffix | create-suffix | delete-suffix...
parameter::= <parameters to connect to the DS instance (port, credential..)>
options::= <option to process the command and also some properties>

Then we have specific <verb-resource> to define the resource properties (entry cache size, directory path, type of replica...)

They are set-suffix-prop, set-backend-prop...
Basically once the resource has been created (with some properties), any 'properties' of the resource can be read/write by set/get-<resource>-prop.

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-<resource>-prop function have a similar interface.

I do not know if I answer correctly your concerns. Just let me know if I missed your questions.

regards
thierry
On 01/03/2014 01:10 PM, Roberto Polli wrote:
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:

Ticket https://fedorahosted.org/389/ticket/47625 changes the interface
of DirSrv.
This ticket is the porting side of the test cases to the new interface

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. 


https://fedorahosted.org/389/attachment/ticket/47628/0001-Ticket-47628-port-> testcases-to-new-DirSrv-interface.patch