Le 22/04/2010 16:43, Sebastien Bahloul a écrit :
Hi Jonathan,
Le mardi 20 avril 2010 19:03:34, Jonathan Clarke a écrit :
This is very interesting. I've just read through it all,
First, thank you for this :)
It's a pleasure - this is really driving LSC where we've wanted it to go
for a long time :)
and here are some comments:
I note that you placed the SimpleScriptingDstService class in the
org.lsc.scripting package. If we consider that the number of services
may grow strongly in the future, this is not an extensible naming
scheme. I propose to add a hierarchy of packages under
"org.lsc.services", for each type of service, including a sub-package
for a services specific classes, if any. What do you think?
I completely agree: so org.lsc.services.executable ?
Actually, services or connectors ? I think I prefer connectors. But I
don't feel strongly - which do you prefer ?
I understand. I see no reason for this to be limited to scripts though -
any executable that can read stdin and output through stdout and stderr
will work :)
So Scripting => Executable ?
OK.
Thank you for taking some time to look at it, at least to check for :
- the IDestinationService to introduce different destination services
- in the SimpleScriptingDestinationService, for the way the scripts are
called.
I see that IDestinationService defines apply(JndiModifications).
Therefore, it is a JNDI-only destination interface, and I suggest it be
renamed IJndiDestinationService.
Fixed
Actually, I've been thinking some more about the naming of these interfaces.
Since your last commit, the only difference between a "dst" service and
a "src" service is that the "dst" has an extra method, apply(). So we
could easily have connectors that work for both source AND destination.
The executable one could easily be used as a source connector too.
Similarly we currently have "SimpleJndiDstService" and
"SimpleJndiSrcService" which are almost identical... they could be merged.
So maybe we can keep IService (for a minimum service that can read), and
rename IJndiDestinationService to IJndiWritableService ?
In the end, we should have our own internal format to store
modifications for a general purpose destination service.
Similarly, SimpleScriptingDestinationService should be
SimpleScriptingJndiDestinationService or maybe just
ScriptingJndiDestinationService ?
I suggest ExecutableJndiDestinationService ?
We should remove Destination (as discussed above).
Also, from a user's point of view, the executables get LDIF, not JNDI,
so I think we should call it ExecutableLdifService. Does that make sense?
At this time the scripts are only provided as Unix Shell scripts that
depend upon ldapsearch/add/modify/... tools. Ldap2Ldap tests have been
duplicated to check for completeness and are fully fonctional. To
complete this implementation, it will require to write some .bat / .ps1
scripts and to put some checks inside the Unix implementation.
Well, if I understand correctly, these shell scripts are just for test
purposes? So, maintaining two sets of scripts (Unix shell and .bat/.psl)
sounds like a lot of complicated work for just tests.
But maven and tests can also be run in other platforms ...
Absolutely, I'm not saying they shouldn't be. Our tests must work on all
platforms where the LSC works. I agree completely.
Why not implement these "scripts" in some platform-independant language?
We could easily write some simple Java tools that reproduce the
behaviour described, and would work on all platforms. What do you think?
I agree but what kind of language that is embeddable in the LSC package ?
Java! All our code is already in Java, so any development environement
will already have a Java compiler, and Maven. I'm thinking: just use
very simple Java programs (completely independant from LSC code), like
these, to include in tests for this service:
http://www.unboundid.com/products/ldapsdk/docs/examples/index.php
These will then work with tests on any platform LSC runs on.
Of course, all this needs documenting too. In this regard, I suggest we
add a hidden section to the wiki, like doc/future/ so we can add new
temporary docs here, if necessary.
Would like to but how can we create an hidden section ?
It doesn't have to be private (as in not accessible). We can just create
a section with no links to it, like :
http://lsc-project.org/wiki/documentation/future/start
Jonathan
--
--------------------------------------------------------------
Jonathan Clarke - [email protected]
--------------------------------------------------------------
Ldap Synchronization Connector (LSC) - http://lsc-project.org
--------------------------------------------------------------
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org
lsc-dev mailing list
[email protected]
http://lists.lsc-project.org/listinfo/lsc-dev
