On Dec 18, 2008, at 15:26 , Peter Soetens wrote:

>>> ...
>> It seems that one possibility is to extend RTT::Toolkit to have a
>> registerTransports() to it, and then use the RTT::Toolkit structure
>> pretty much as is. The difference between an RTT plugin and its
>> associated Corba transport library, is just that different functions
>> within a toolkit are implemented.
>>
>> The other possibility seems to be add a parallel RTT:Transport
>> structure, which mirrors the RTT::Toolkit structure. The
>> corresponding
>> TransportPlugin would have registerTransport() and loadTypes()
>> functions (the RTT CorbaLib does both, whereas the KDL and my OpenCV
>> plugins just register transports). This approach I think would force
>> mod's on the deployer, as well as add static transport objects to
>> each
>> plugin.
>>
>> The first approach seems simpler, keeping just one type of plugin,
>> but
>> it does muddle up a little the type/transport concepts. The second
>> approach keeps the semantic separation but is more work (IMHO).
>
> The first option is better anyway, having a single point of access for
> very related classes. I would however extend Toolkit with a
> static std::vector<TransportRegistrator*> Transports;
> , a getTransports()/hasTransport(string) query and the
> Import(TransportRegistrator) method mentioned earlier. The
> ToolkitPlugin
> class is not modified. We use the TransportRegistrator instead (which
> should be renamed to TransportPlugin for consistency, and defined in
> TransportPlugin.hpp, ToolkitPlugin+macro would/could move to
> ToolkitPlugin.hpp and let Toolkit.hpp include both anyway.)
>
> Similarly, an ORO_TRANSPORT_PLUGIN macro is defined which transforms
> the
> transport library into a plugin.
>
>>
>> What is the semantic difference between a plugin and a toolkit?
>> Perhaps the answer to this would help chose?
>
> The 'generic' plugin API of RTT is defined by
>
> namespace RTT { class TaskContext; }
> extern "C" {
> bool loadRTTPlugin( RTT::TaskContext* );
> std::string getRTTPluginName();
> }
>
> (yes we should put this definition in a file Plugin.hpp !). We now
> only
> have one plugin type: the toolkit. After your change, we would have
> two
> plugin types: toolkits and transports. That's what the macro does in
> Toolkit.hpp
>
>>
>> I'm willing to take a first stab at this, once we decide on a basic
>> approach.
>
> I have a pretty clear picture of what I would do. But I'll leave the
> honour to you anyway :-)

You asked for it ... :-) ... nasty big patch associated, along with
KDL fixes also. This clean builds/runs under Linux for RTT, KDL, BFL,
and OCL.

One thing, I'm not entirely sure of the way you wanted to handle
Plugin.hpp vs ORO_TOOLKIT_PLUGIN(). Let me know if this is (not) what
you had in mind.

Cheers
S

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

>>>
>>> The only reason the rtt plugins can self-load is because they are
>>> linked
>>> explicitly with the executable. We saw problems with this earlier
>>> iirc, so
>>> importing and/or loading from the deployer or C++ should always be
>>> possible.
>>
>> Do you remember what problems? One course of action for plugins in
>> general is maybe to always self-load. Linking into an application (or
>> dynamically loading when the app starts) would cause self-load, as
>> would importing within a Deployer XML file. An immediate issue might
>> be the order that dynamic libraries for an application are loaded,
>> although I _think_ that if the dependancies are set when each library
>> is linked that the O/S dynamic loader might take care of this. Of
>> course, making your own toolkit/plugin self-load is always an option
>> for each user creating them.
>
> It was Ruben who had the problem with KDL: if the self-loading
> plugin was
> linked with a component, and the component loaded in the deployer, the
> toolkit was not doing the self-load thing. We fixed it back then with
> letting the deployer search for plugins during startup.

Umm ... well ... I don't think you guys did actually fix this as it
doesn't work for non-standard install locations (like mine). :-(

We have to forcibly load the KDL toolkit and the KDL corba plugin into
an application. We also import them explicitly within XML deployment
files.

If we are going to have the deployer self-load plugins, we need to be
able to set the directory it searches in. This lead you and I a while
back to talk of an XML configuration of the deployer. But is this the
right answer? I don't think so. Perhaps the user doesn't want all
plugins in a directory to be self-loaded? What if they have them from
multiple directories?

Isn't a plugin library really just the same as a component library, as
far as the deployer is concerned. An import statement tells it to load
the library and then internally, with functionality that already
exists, the deployer loads any components or plugins or toolkits that
it finds within that library. The onus is then on the application's
XML file to specify which libraries/toolkits/plugins/components that
they want, and to order them correctly to deal with dependancies
(well, someone has to do it, either the application programmer or the
dynamic loader).

Thoughts?
S

>> What is the semantic difference between a plugin and a toolkit?
>> Perhaps the answer to this would help chose?
>
> The 'generic' plugin API of RTT is defined by
>
> namespace RTT { class TaskContext; }
> extern "C" {
> bool loadRTTPlugin( RTT::TaskContext* );
> std::string getRTTPluginName();
> }

As all good programmers know, this is a bad contract. I meant to write:

/**
* @file Plugin.hpp
* This file defines the Orocos plugin API.
* A plugin is a dynamic library which has a unique name and
* can be loaded in a running application. In case the loading
* is done by an Orocos TaskContext, the plugin is notified of
* the loading TaskContext. A plugin can reject to load, in which
* case the library should be unloaded from the application again.
* Once loaded, a plugin remains in the current process until the
* process exits.
*/
#include
namespace RTT { class TaskContext; }
extern "C" {
/**
* Instructs this plugin to load itself into the application.
* Implement in this function any startup code your plugin requires.
* This function should not throw.
*
* @param t The optional TaskContext which is loading this plugin.
* May be zero.
* @return true if the initialisation succeeded, false if the
* plugin could not do so.
*/
bool loadRTTPlugin( RTT::TaskContext* t );

/**
* Return the unique name of this plugin. No two plugins with
* the same name will be allowed to live in a single process.
*/
std::string getRTTPluginName();
}

Probably not perfect, but better anyway.

Peter