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 :)
> 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 ?
> Regarding configuration, I see that you use subkeys of
> lsc.tasks.ldap2scriptTestTask.dstService to pass both script names and
> parameters. I think it would be clearer, and safer, to have two
> sub-levels, like:
> lsc.tasks.ldap2scriptTestTask.dstService.scripts.list = ...
> lsc.tasks.ldap2scriptTestTask.dstService.scripts.add = ...
> lsc.tasks.ldap2scriptTestTask.dstService.vars.MY_ENV_VAR = ...
OK, fixing
> The output from scripts, on stderr, seems to be displayed on a DEBUG log
> level only. Maybe we could implement a convention for scripts to display
> messages at different levels by prefixing messages on stderr?
>
> I don't understand why you simplify the method
> getFullDistinguishedName() from LscBean like this. Are you sure that the
> distingushedName local attribute is complete now? It didn't use to be,
> but things may have changed since revision 179 :)
>
> > At this time, it is doing exactly the same thing that ldap2ldap does
> > through the provided scripts, but then you can add everything you want
> > inside the 6 scripts (list, get, add, update, rename, delete) to
> > provision external systems through simple commands
>
> 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 ?
> > It may also contains some stuff about JMX and asynchronous mode that have
> > not been commited at this, but this is not the important part.
>
> Yes, indeed. This patch is quite hard to read, since it mixes in changes
> about a "Task" object, JMX, comment reformatting, etc... Please don't
> commit as is, it would be a *nightmare* to track changes, issues, etc! :)
OK, I will start with this IDestinationService and Executable scripts. We will
discuss later about jmx, ...
> > 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
> 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 ?
> > To explain it in a short way, scripts are called with :
> > - environment variables which contains parameters passed in
> > lsc.properties, - a optional single parameter which is the object main
> > identifier (dn), - a stdin stream on which the LDIF is written by the
> > service (update ldif format for update scripts, LDIF search entry format
> > for get)
> > - a stdout stream which is read for data
> > - a stderr stream which is read for messages
> > - a return code
>
> I like the idea of good old standard interaction with executables:
> std{in,out,err}, environment variables and return codes. It'll probably
> be required to have more command line options at some point, but this
> looks good for now.
>
> In fact, if one puts some command line options in the configuration, are
> these arguments correctly passed? Like this:
> lsc.tasks.ldap2scriptTestTask.dstService.scripts.list = ldapsearch -x -b
> o=test ...
I agree but I will check for this later.
> Using LDIF only for communication may become limiting at some point
> though... It seems a bit weird to me to have to implement a set of shell
> scripts that read LDIF to write to a database, for example.
> I don't currently have any better suggestions for the format to use,
> though.
Any other format suggestion welcomed :)
> > 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 ...
> 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 ?
> 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 ?
> This is quite a long email, I hope I've been clear. Please ask if I'm not!
Thanks a lot.
> >
> Jonathan
>
--
Sebastien BAHLOUL
IAM and Security Solutions Manager
LINAGORA : http://www.linagora.com/
Tel / Phone : +33 810 251 251
Mobile : +33 (0)6 45 63 27 39
74/80 rue Roque de Fillol
92800 Puteaux
-----------
http://linid.org/ - http://linpki.org/
IAM and security Open Source projects
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org
lsc-dev mailing list
[email protected]
http://lists.lsc-project.org/listinfo/lsc-dev
