<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>
<admin_cmd> <verb-resource> [parameters] [options]<br>
<br>
admin_cmd::= "dsadmin"<br>
verb-resource::= <verb-suffix> | <verb-replication>
| <verb-backend> |...<br>
<verb-suffix> ::= list-suffix | create-suffix |
delete-suffix...<br>
parameter::= <parameters to connect to the DS instance (port,
credential..)><br>
options::= <option to process the command and also some
properties><br>
<br>
Then we have specific <verb-resource> 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-<resource>-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-<resource>-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>-> testcases-to-new-DirSrv-interface.patch
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>