<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
On 04/22/2011 11:51 PM, Jean-Christophe Fillion-Robin wrote:
<blockquote
cite="mid:BANLkTikPz8vho4N-BNP3nE5N-4mKN91k=Q@mail.gmail.com"
type="cite">Hi Folks, <br>
<br>
Hope everything is going well :) <br>
<br>
I will perform the following change:<br>
<br>
A) Comment the line adding CTK/Libs/ModuleDescription to CTK
build system. This later one doesn't compile<br>
<br>
.. and I would like to perform the following changes:<br>
<br>
1) Delete CTK/Plugins/org.commontk.cli ("Interface that allows to
discover and manage CLI modules") <br>
=> description is "Interface that allows to discover and
manage CLI modules" (see servicedescriptor.xml)<br>
=> Is that used ? Seems all classes are empty<br>
</blockquote>
<br>
Let's remove it. I never had time to finish it and would do it
slightly different now anyway.<br>
<br>
<blockquote
cite="mid:BANLkTikPz8vho4N-BNP3nE5N-4mKN91k=Q@mail.gmail.com"
type="cite"><br>
2) Rename CTK/Libs/PluginFramework into
CTK/Libs/Plugin/Framework<br>
<br>
3) Move CTK/Libs/ModuleDescription into more specialized
subfolder CTK/Libs/Plugin/Description<br>
=> Classes would be rename into:
ctkPluginDescription[ExecutionInterface, Parameter,
ParameterGroup... ]<br>
<br>
Note also that: <br>
Enabling CTK_LIB_PluginDescription and CTK_LIB_PluginFramework
could be enabled independently <br>
<br>
</blockquote>
<br>
I think I understand what you are aiming for, but I am not really
happy with the generic names. And if the two libraries are called
"CTKPluginFramework" and "CTKPluginDescription", the names suggest a
relationship where actually no relationship exists between the two
(except that they both provide some kine of "extension mechanism").<br>
<br>
What about:<br>
<br>
CTK/Libs/ExtensionMechanisms/PluginFramework ( will be called
libCTKPluginFramework.so )<br>
CTK/Libs/ExtensionMechanisms/CommandLineModule ( will be called
libCTKCommandLineModule.so )<br>
<br>
and rename the files to ctkCommandLineModule[ExecutionInterface,
Parameter, ParameterGroup... ] ?<br>
<br>
Let's also see what J2 and Xavier think.<br>
<br>
<blockquote
cite="mid:BANLkTikPz8vho4N-BNP3nE5N-4mKN91k=Q@mail.gmail.com"
type="cite"><br>
4) Move plugin "CTK/Plugins/org_commontk_slicermodule" into for
example <a moz-do-not-send="true"
href="http://github.com/slicer/org_slicer_module">github.com/slicer/org_slicer_module</a>
or some other project hosted on <a moz-do-not-send="true"
href="http://github.com/slicer">github.com/slicer</a> that could
host all plugin and library specific to slicer.<br>
<br>
</blockquote>
<br>
I think for the CTK "Core Team", it would make things easier if
org_commontk_slicermodule would stay where it is, for the time being
(what would be your motivation for moving it?). I am thinking about
possible refactorings and test and integration scenarios (other
toolkits like MITK trying to use the org_commontk_slicermodule
plugin). Until the code is "stable" the current form allows us to
modify and test it more easily.<br>
<br>
<br>
Thanks for cleaning up, and Happy Easter (to all who celebrate it)
:-)<br>
<br>
Sascha<br>
</body>
</html>