On Jan 20, 2011, at 03:36 , Ruben Smits wrote:

> On Thursday 20 January 2011 03:25:28 S Roderick wrote:
>> Just wondering about the motivation behind yesterday's removal of all RTT
>> references from KDL? Including the plugin that some of us use. What is the
>> long term plan for KDL to provide support in Orocos applications that use
>> RTT and KDL?
>
> Since I'm in the middle of moving KDL from svn to git, I thought it was time
> to clean up kdl a little bit.
>
> We pulled out the rtt plugin and have put in its own package. I'm wondering if
> we should do the same for the python bindings?
>
> I probably should make a tag with the state before the removal.
>
> The resulting orocos_kinematics_dynamics git repository will have three
> packages: kdl, kdl_typekit, kdl_python(or something similar)
>
> So users that are only interested in the bare kdl library can build only kdl
> and leave the rest untouched.
>
> All kdl packages will always be released as a singleton.

Singleton?

> If someone has strong objections to this please speak up.

All of this reasoning sounds good, but it would have been really nice to have had some communication up front of the intentions.

Will KDL be hosted on gitorious, github, ...?

Will it be hosted in the Orocos project, or is it to be kept separate?

Glad to hear about the transformation to git. Dissapointed at the surprise of this move.
S

On Thu, 20 Jan 2011, Steven Bellens wrote:

> 2011/1/20 S Roderick <kiwi [dot] net [..] ...>:
>> Just wondering about the motivation behind yesterday's removal of all RTT references from KDL? Including the plugin that some of us use. What is the long term plan for KDL to provide support in Orocos applications that use RTT and KDL?
>
>> From where do you download KDL?
> We've been busy last days refactoring the KDL RTT plugin in order to
> support all KDL types in RTT. These changes are all on git and no
> change on the svn is made (?). Ruben planned to move the complete
> source code from svn to git as well in the next days.
>
> Steven
>

The "Big idea" behind this is that KDL should offer useful functionality
("Computations") with as few dependencies on other things (such as RTT),
where the core reason for the existence of RTT is exactly to provide the
support (the "component model infrastructre") to embed as much of such
independently developed as possible. So, in summary: it makes more sense
that RTT knows about how to plug in libraries, than that those libraries
have to know about RTT. What holds for KDL also holds for any other
functionality library.

But, of course, we remain very open for better insights about the trade-off
between the opposing design forces of decoupling and integration.

>> Cheers
>> S

Herman