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
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/389-devel
