On Mon, 23 Aug 2010, S Roderick wrote:

> On Aug 23, 2010, at 07:54 , Peter Soetens wrote:
>
>> On Monday 23 August 2010 13:41:00 Peter Soetens wrote:
>>> I'm about to move a patch to master that modifies <ocl/Component.hp

such
>>> that a component that must be loaded by the DeploymentComponent, must
>>> be compiled with the flag '-DRTT_COMPONENT' instead of '-DOCL_DLL_EXPORT'.
>>>
>>> For 'transition' reasons, both old and new style will still work in the
>>> coming releases, but it is recommended that you change this asap. Both 2.0
>>> and 1.12 will have this change. Win32 users will even have no other
>>> choice, since on that platform, OCL_DLL_EXPORT does not work, and they
>>> need to use
>>> RTT_COMPONENT.
>>>
>>> Patch FYI in attachment.
>>
>> Another improvement I forgot to mention is that with this patch, it won't be
>> necessary any longer to link with liborocos-ocl-common, your component will
>> only link with the RTT. One may wonder in that case if the header should
>> belong in rtt in the first place...
>
> Header belongs with the code that loads components from dynamic
> libraries, which is the deployer, isn't it? So it should stay in OCL? Or
> should that mean that the deployer is promoted to RTT ... cue Herman
> comment here ... :-)

Maybe I do not fully understand the issues at hand here, but here are some
comments to S's smiley remark :-)
- I think we see an example of "dependency creep" here: I have the
impression that the only reason to put the header into RTT is to support
deployment.
- that's not a good reason in itself, although the _need_ is definitely
there and motivated.
- the "software engineering pattern" that might come to the rescue here is
that of "dependency injection", "inversion of control", "dynamic
services", or whatever name is given to it in the different sub-domains
that have re-invented the pattern:
- one needs to _couple_ two "things" when making a system, but one does
not want to include coupling information in both "things", or even
in only one of them.
- the solution is to fully decouple both "things" and introduce a third
"thing" for the sole purpose of doing the coupling (and nothing more
than that) in a neutral way.
- concretely speaking: an "OCL" component should have an "XML" file that
contains all the information that a deployer needs to have in order to
make the requested coupling at deployment time; RTT should get the
generic functionality to be able to communicate with the "third thing"
about the what it should do with that information _in general_, for
the purpose of "out-sourcing" the deployment functionality; the 'system
architect' then only has to do the appropriate "configuration" of all three
things in the system.

Herman

On Monday 23 August 2010 14:07:42 S Roderick wrote:
> On Aug 23, 2010, at 07:54 , Peter Soetens wrote:
> > On Monday 23 August 2010 13:41:00 Peter Soetens wrote:
> >> I'm about to move a patch to master that modifies <ocl/Component.hp

> >> such that a component that must be loaded by the DeploymentComponent,
> >> must be compiled with the flag '-DRTT_COMPONENT' instead of
> >> '-DOCL_DLL_EXPORT'.
> >>
> >> For 'transition' reasons, both old and new style will still work in the
> >> coming releases, but it is recommended that you change this asap. Both
> >> 2.0 and 1.12 will have this change. Win32 users will even have no other
> >> choice, since on that platform, OCL_DLL_EXPORT does not work, and they
> >> need to use
> >> RTT_COMPONENT.
> >>
> >> Patch FYI in attachment.
> >
> > Another improvement I forgot to mention is that with this patch, it won't
> > be necessary any longer to link with liborocos-ocl-common, your component
> > will only link with the RTT. One may wonder in that case if the header
> > should belong in rtt in the first place...
>
> Header belongs with the code that loads components from dynamic libraries,
> which is the deployer, isn't it? So it should stay in OCL? Or should that
> mean that the deployer is promoted to RTT ... cue Herman comment here ...
> :-) S
>

Nevermind my last comment, now is not the time to spend energy in this. It
will stay where it is.

Peter