Definitely yes.

I'm a big fan of small packages/repositories that can be selected by the
user to meet their needs, with a good tool that automates making sure
essentials are installed. My experience with Player and Gearbox has
soured my taste for monolithic distributions. For an example, see your
local Linux distribution, or ROS. :)

I know we've spoken about this stuff in the past, Peter. Stuff is slowly
happening. There's a patch on the ROS trac, and although it did turn out
to be not quite where WG wants to go, it looks like we'll get that
separate package manager soon now.

Geoff

On 02/07/10 21:02, Peter Soetens wrote:
> I agree that ease of use is on the first place. We have however a bunch of
> unmaintained code in OCL which, I as a maintainer, hate to have in there.
> The main painpoint is that I don't feel responsible for maintaining that code,
> I can't test it (other than that it compiles), and can only wait for patches,
> which don't come. In the meantime, the people that wrote that code are setting
> up different repositories and are maintaining these. I'd rather move the code
> to that place and let it to them to decide to remove it or keep it in.
>
> Actually, I think we agree on the approach to take, make OCL a must-have lib
> for every user, and put all must-haves into OCL, while we put all 'lab-X',
> 'lab-Y' specific code in their own repositories.
>
> Or not ?

On Jul 2, 2010, at 08:02 , Peter Soetens wrote:

> On Friday 02 July 2010 12:58:37 Stephen Roderick wrote:
>> On Jul 2, 2010, at 05:55 , Peter Soetens wrote:
>>> On Thursday 01 July 2010 13:34:12 S Roderick wrote:
>>>> On Jun 30, 2010, at 11:48 , Peter Soetens wrote:
>>>>> I'm looking into the 'component finding' problem for OCL and
>>>>> applications in general. Current ocl installs its components as
>>>>> /usr/lib/lib*.so, which is bad for our deployment component. The idea
>>>>> is to change this to /usr/lib/orocos/lib*.so such that we can do an
>>>>> import of /usr/lib/orocos and only find components instead of 987 other
>>>>> libraries.
>>>
>>> ...
>>>
>>>> So what gets loaded when? Is the deployer automatically doing an import
>>>> of all of /usr/lib/orocos? If so, is there a way to prevent that? I
>>>> presume that installing somewhere besides /usr/lib will be taken care of
>>>> (it's /opt/2.0 above).
>>>
>>> It will import ${OROCOS_INSTALL}/lib/orocos if:
>>> * no RTT_COMPONENT_PATH env variable was set
>>> * no RTT_COMPONENT_PATH property was set in DeploymentComponent (using a
>>> site file).
>>>
>>> In my example, OROCOS_INSTALL was set to /opt/2.0 when building OCL. We
>>> need this path to find the RTT typekits and plugins anyway.
>>
>> Ok, so the system will automatically import all typekits and plugins. How
>> much has the definition of a "typekit" or a "plugin" changed from v1 to
>> v2? (ie what is actually getting imported).
>
> The 'C' API of plugins was only slightly extended with one extra function:
> getRTTTargetName() which is optional. Only loadRTTPlugin(TaskContext*) is
> mandatory btw.
>
> The C++ API of transport plugins (TransportPlugin) which is in addition to
> this 'C' API, has been slightly extended to with respect to getName() and
> getTransportName().
>
> typekits provide an subclass of TypekitPlugin and register that class using
> RTT_TYPEKIT_PLUGIN. This class is then queried once to load its types or
> transports into the process.
> For normal 'plugins', no class must be implemented and the presence of the
> Plugin.hpp functions are enough.
> The macro RTT_SERVICE_PLUGIN defines these functions in case you subclassed
> ServiceProvider in your plugin (like scripting and marshalling do). For each
> plugin that is not a typekit, you can request that it is loaded into a
> TaskContext. The plugin can refuse this.
>
> This needs to be documented better in the plugin manual....
>
>>
>>>> Does the deployer support multiple paths in RTT_COMPONENT_PATH?
>>>
>>> Of course !!! Just like plain 'Unix' PATH. It's *not* recursive. I'm
>>> pondering about a recursive search that only considers a child directory
>>> if it contains a 'manifest.xml' file. This would allow us to work closely
>>> with ros-style layouts of applications (ie component libs are spread over
>>> package directories).
>>>
>>>> Separately, why do RTT libraries have an "rtt-" prefix, but only one OCL
>>>> library does? Why aren't all OCL libraries "libocl-XXX"?
>>>
>>> I'll probably open the gates of angry-user-feedback hell when I'm doing
>>> more renames, especially if folks directly link to taskbrowser and
>>> deployer libs.
>>
>> What, you haven't seen any of that feedback yet?! ;-)
>
> Well, let's say that the doors were already slightly ajar.
>
>>
>>> OCL's refactoring into multiple repositories (separating infrastructure
>>> components maintained by me from application components developed by PMA)
>>> is also still on the list. So I'm not sure the name OCL will even
>>> survive... 'Orocos-taskbrowser' and 'orocos-deployement' don't look that
>>> bad in that respect.
>>
>> I'm against this suggestion. Maintainers come and go. It also will bundle
>> essentially functionally arbitrary chunks of code together.
>
> Isn't this what OCL is today ?
>
>> Why not stick
>> with a functional separation? Isn't this about cohesiveness?
>
> It's what I try to achieve !
>
>> If we go by
>> maintainer, ditch OCL all together and provide github (or similar) links
>> for each maintainer! Otherwise we're making it easier on the developer
>> rather than easier on the user. That's a bad policy.
>
> I agree that ease of use is on the first place. We have however a bunch of
> unmaintained code in OCL which, I as a maintainer, hate to have in there.
> The main painpoint is that I don't feel responsible for maintaining that code,
> I can't test it (other than that it compiles), and can only wait for patches,
> which don't come. In the meantime, the people that wrote that code are setting
> up different repositories and are maintaining these. I'd rather move the code
> to that place and let it to them to decide to remove it or keep it in.
>
> Actually, I think we agree on the approach to take, make OCL a must-have lib
> for every user, and put all must-haves into OCL, while we put all 'lab-X',
> 'lab-Y' specific code in their own repositories.

Yes. Do you have an initial list of what will stay in OCL (the so called "infrastructure components")?

I actually think OCL has a degree of functional cohesiveness in its existing structure. It can always be improved upon, but it's not terrible now.
S

On Friday 02 July 2010 13:36:37 Hugo Garcia wrote:
> On Fri, Jul 2, 2010 at 12:58, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
> > On Jul 2, 2010, at 05:55 , Peter Soetens wrote:
> >> On Thursday 01 July 2010 13:34:12 S Roderick wrote:
> >>> On Jun 30, 2010, at 11:48 , Peter Soetens wrote:
> >>>> I'm looking into the 'component finding' problem for OCL and
> >>>> applications in general. Current ocl installs its components as
> >>>> /usr/lib/lib*.so, which is bad for our deployment component. The idea
> >>>> is to change this to /usr/lib/orocos/lib*.so such that we can do an
> >>>> import of /usr/lib/orocos and only find components instead of 987
> >>>> other libraries.
> >>
> >> ...
> >>
> >>> So what gets loaded when? Is the deployer automatically doing an import
> >>> of all of /usr/lib/orocos? If so, is there a way to prevent that? I
> >>> presume that installing somewhere besides /usr/lib will be taken care
> >>> of (it's /opt/2.0 above).
> >>
> >> It will import ${OROCOS_INSTALL}/lib/orocos if:
> >> * no RTT_COMPONENT_PATH env variable was set
> >> * no RTT_COMPONENT_PATH property was set in DeploymentComponent (using a
> >> site file).
> >>
> >> In my example, OROCOS_INSTALL was set to /opt/2.0 when building OCL. We
> >> need this path to find the RTT typekits and plugins anyway.
> >
> > Ok, so the system will automatically import all typekits and plugins. How
> > much has the definition of a "typekit" or a "plugin" changed from v1 to
> > v2? (ie what is actually getting imported).
> >
> >>> Does the deployer support multiple paths in RTT_COMPONENT_PATH?
> >>
> >> Of course !!! Just like plain 'Unix' PATH. It's *not* recursive. I'm
> >> pondering about a recursive search that only considers a child directory
> >> if it contains a 'manifest.xml' file. This would allow us to work
> >> closely with ros-style layouts of applications (ie component libs are
> >> spread over package directories).
> >>
> >>> Separately, why do RTT libraries have an "rtt-" prefix, but only one
> >>> OCL library does? Why aren't all OCL libraries "libocl-XXX"?
> >>
> >> I'll probably open the gates of angry-user-feedback hell when I'm doing
> >> more renames, especially if folks directly link to taskbrowser and
> >> deployer libs.
> >
> > What, you haven't seen any of that feedback yet?! ;-)
> >
> >> OCL's refactoring into multiple repositories (separating infrastructure
> >> components maintained by me from application components developed by
> >> PMA) is also still on the list. So I'm not sure the name OCL will even
> >> survive... 'Orocos-taskbrowser' and 'orocos-deployement' don't look that
> >> bad in that respect.
> >
> > I'm against this suggestion. Maintainers come and go. It also will bundle
> > essentially functionally arbitrary chunks of code together. Why not stick
> > with a functional separation? Isn't this about cohesiveness? If we go by
> > maintainer, ditch OCL all together and provide github (or similar) links
> > for each maintainer! Otherwise we're making it easier on the developer
> > rather than easier on the user. That's a bad policy.
> >
> > S
> > --
> > Orocos-Dev mailing list
> > Orocos-Dev [..] ...
> > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
> Is this the thread and work where you will provide the option for the
> deployment component to provide XML component descriptions of the
> components found in the libraries?

No, but it would be an excellent example as an RTT v2 plugin. It could be
loaded in the deployment component, iterate over all peers and generate these
files for each peer. Different plugins could generate different file formats. Our
marshalling plugin is already doing something like that: it scans the
properties of the current component and writes them to a file.

> Will the directory where the
> component descriptors be user defined or will you have have a specific
> directory like 'component_library"?

This is part of a larger problem, related to manifest.xml files and any meta-
file that tools need to work with our components. I would install any meta file
with the component library in the same location. Where components are
installed is up to the user. He'll just have to add this installation path to
his RTT_COMPONENT_PATH

> Will the component library have
> separate directories for Orocos provided components and another
> directory for user provided components?

Orocos installs its components in [/usr]/lib/orocos, It doesn't matter if user
components install there too or in another location. This will only have effect
on the RTT_COMPONENT_PATH environment variable.

Peter