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
|
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
