New RTT 2.0 namespace and directory structure

As Sylvain suggested before, the RTT needs a cleaner directory
structure. I propose one, you guys shoot at it. Ok ?

I couldn't get this nicely formatted in an email, so I've put it in the wiki:
http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup/direc...

We can discuss it here, or if you 'Add new comment', It will appear on
the 'Talk' page of the wiki.

It's very drafty, but I'm aiming for 'about 10' headers in rtt/*.hpp
and the rest in subdirectories.

Peter

New RTT 2.0 namespace and directory structure

On Thu, Jun 18, 2009 at 14:23, Peter Soetens<peter [dot] soetens [..] ...> wrote:
> As Sylvain suggested before, the RTT needs a cleaner directory
> structure. I propose one, you guys shoot at it. Ok ?
>
> I couldn't get this nicely formatted in an email, so I've put it in the wiki:
> http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup/direc...
>
> We can discuss it here, or if you 'Add new comment', It will appear on
> the 'Talk' page of the wiki.
>
> It's very drafty, but I'm aiming for 'about 10' headers in rtt/*.hpp
> and the rest in subdirectories.

It became 16 headers. For a (non compiling) preview, see the
rtt-2.0-refactoring branch on github:
http://github.com/psoetens/orocos-rtt/tree/rtt-2.0-refactoring

The refactoring is extreme and I'm not yet 100% satisfied. Strangeness about:
- dev/* -> does it belong in RTT or in OCL ?
- property/* -> is former marsh/* + property helper classes. Property
marshalling is in need of a refactoring and I wonder if we need to
make it as configurable as it is now.
- interface/* -> some of these classes are probably 'internal
interfaces' and should move to internal/

There's also a bunch of classes (FunctionGraph, StateMachine,
Condition*, Command*,...) which is only used by scripting. I've put it
now in internal, but does it really belong there ??

Also, dataflow, property helper classes have subdirectories; but
event, method, command helpers are just in internal/. I was thinking
about creating an 'execution' subdirectory to gather all related to
these three, but it felt to fragmented already. Same for a
subdirectory called 'taskcontext', to gather all helper classes for
the TC. The last thing I want is getting lost in the subdirectories.
It doesn't feel balanced yet.

Looking at it again, it would maybe be best if we could succeed in
dropping the 'vague' internal subdir and have something like

rtt/ (16 headers as on github)
rtt/interface (fundamental interfaces)
rtt/property (all about properties)
rtt/dataflow
rtt/operations (method/command/event/attribute related)
rtt/scripting (including graph, statemachine etc from above)
rtt/os
rtt/os/targets
rtt/corba
rtt/plugin
rtt/types
rtt/extras

Better ?

Peter

New RTT 2.0 namespace and directory structure

> The refactoring is extreme and I'm not yet 100% satisfied. Strangeness
> about: - dev/* -> does it belong in RTT or in OCL ?
For me they belong to extras/.

They're too generic to be in OCL, but not generic enough to be in the RTT
core.

> - property/* -> is former marsh/* + property helper classes. Property
> marshalling is in need of a refactoring and I wonder if we need to
> make it as configurable as it is now.

> rtt/ (16 headers as on github)
> rtt/interface (fundamental interfaces)
> rtt/property (all about properties)
> rtt/dataflow
> rtt/operations (method/command/event/attribute related)
> rtt/scripting (including graph, statemachine etc from above)
> rtt/os
> rtt/os/targets
> rtt/corba
> rtt/plugin
> rtt/types
> rtt/extras
>
> Better ?

I would suggest one more depth in directories:
rtt/corba => rtt/transports/corba

This would make RTT more marketable with people that are allergic to CORBA.

Also, maybe have rtt/interface/* move to rtt/ and use rtt/interface for the
TaskContext interface-related helpers (i.e. rtt/operations/* and
rtt/dataflow/*)

Thoughts ?
Sylvain

New RTT 2.0 namespace and directory structure

On Fri, 19 Jun 2009, Sylvain Joyeux wrote:

>> The refactoring is extreme and I'm not yet 100% satisfied. Strangeness
>> about: - dev/* -> does it belong in RTT or in OCL ?
> For me they belong to extras/.
>
> They're too generic to be in OCL, but not generic enough to be in the RTT
> core.
>
>> - property/* -> is former marsh/* + property helper classes. Property
>> marshalling is in need of a refactoring and I wonder if we need to
>> make it as configurable as it is now.
>
>
>> rtt/ (16 headers as on github)
>> rtt/interface (fundamental interfaces)
>> rtt/property (all about properties)
>> rtt/dataflow
>> rtt/operations (method/command/event/attribute related)
>> rtt/scripting (including graph, statemachine etc from above)
>> rtt/os
>> rtt/os/targets
>> rtt/corba
>> rtt/plugin
>> rtt/types
>> rtt/extras
>>
>> Better ?
>
>
> I would suggest one more depth in directories:
> rtt/corba => rtt/transports/corba

"transports" -> "communication" or "ipc" or "middleware" ...

> This would make RTT more marketable with people that are allergic to CORBA.

Which makes up for the largest part of the robotics universe :-)

> Also, maybe have rtt/interface/* move to rtt/ and use rtt/interface for the
> TaskContext interface-related helpers (i.e. rtt/operations/* and
> rtt/dataflow/*)
>
> Thoughts ?

I think I agree with your remarks: "interface" in itself is too general;
"rtt" _is_ (by definition) about the rtt programming interfaces.

Herman

> Sylvain

New RTT 2.0 namespace and directory structure

On Thursday 18 June 2009 14:23:20 Peter Soetens wrote:
> As Sylvain suggested before, the RTT needs a cleaner directory
> structure. I propose one, you guys shoot at it. Ok ?
>
> I couldn't get this nicely formatted in an email, so I've put it in the
> wiki:
> http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup/director
>ies-and-namespace-rework
>
> We can discuss it here, or if you 'Add new comment', It will appear on
> the 'Talk' page of the wiki.

OK. I'll do it here ;-)

While we're at it, maybe renaming the Toolkit or Plugin thing into TypePlugin
? And have rtt/plugin be a rtt/types.

I have myself sometime a hard time remembering that Toolkit is actually ...
well ... just a type repository plugin.

Other than that, I'd rather have ExecutionEngine in the main, and put the
PortInterface and ActivityInterface there as well. People have already shown
interest in creating new port types, so that would make more sense to me.

I don't know for the other interfaces.

Sylvain

New RTT 2.0 namespace and directory structure

On Thu, Jun 18, 2009 at 14:36, Sylvain Joyeux<sylvain [dot] joyeux [..] ...> wrote:
> On Thursday 18 June 2009 14:23:20 Peter Soetens wrote:
>> As Sylvain suggested before, the RTT needs a cleaner directory
>> structure. I propose one, you guys shoot at it. Ok ?
>>
>> I couldn't get this nicely formatted in an email, so I've put it in the
>> wiki:
>> http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup/director
>>ies-and-namespace-rework
>>
>> We can discuss it here, or if you 'Add new comment', It will appear on
>> the 'Talk' page of the wiki.
>
> OK. I'll do it here ;-)
>
> While we're at it, maybe renaming the Toolkit or Plugin thing into TypePlugin
> ? And have rtt/plugin be a rtt/types.

You're partly right. The plugin API does exist and we will need a
plugin dir/ns. Types are loaded as plugins, so building a toolkit
depends on the plugin classes. I propose to separate them in plugin
and types. It's my profound hope that creating 'template type info'
objects and plugins manually is no longer required in RTT 2.0, but
that the resulting .so's are generated by a tool from an IDL file or
ros msg file.

>
> I have myself sometime a hard time remembering that Toolkit is actually ...
> well  ... just a type repository plugin.

Yeah, we need to have TypePlugin, TransportPlugin.

>
> Other than that, I'd rather have ExecutionEngine in the main, and put the
> PortInterface and ActivityInterface there as well. People have already shown
> interest in creating new port types, so that would make more sense to me.

I would keep the rtt/interface/ as a BC directory (de facto since it
are base classes of BC classes in rtt/), so we're just separating
interface (used by framework) from implementation (used by user). It
is clearly the intention that users still can specialise these
interfaces, without being set back to zero with each major release.

ExecutionEngine in main is possible.

I need to do this tomorrow. Anyway, we have time to change our minds
the coming months... Although I hope we get 95% right the first time.

Peter

New RTT 2.0 namespace and directory structure

> > While we're at it, maybe renaming the Toolkit or Plugin thing into
> > TypePlugin ? And have rtt/plugin be a rtt/types.
>
> You're partly right. The plugin API does exist and we will need a
> plugin dir/ns. Types are loaded as plugins, so building a toolkit
> depends on the plugin classes. I propose to separate them in plugin
> and types. It's my profound hope that creating 'template type info'
> objects and plugins manually is no longer required in RTT 2.0, but
> that the resulting .so's are generated by a tool from an IDL file or
> ros msg file.
I personally got a completely different route: to generate the toolkit (and
IDL) from the C++ type instead of the other way around. And that is for a
simple reason: those types are to be used within the context of C++ code, so
having them as C++ definitions *including operators, accessors, setters, ...*
is just the best way. And if you want to move out of ROS, you're not left with
ROS message descriptions ... or with IDL if you're moving out of CORBA.

> > Other than that, I'd rather have ExecutionEngine in the main, and put the
> > PortInterface and ActivityInterface there as well. People have already
> > shown interest in creating new port types, so that would make more sense
> > to me.
>
> I would keep the rtt/interface/ as a BC directory (de facto since it
> are base classes of BC classes in rtt/), so we're just separating
> interface (used by framework) from implementation (used by user). It
> is clearly the intention that users still can specialise these
> interfaces, without being set back to zero with each major release.
I don't really have an opinion on having in interfaces/ or rtt/, so do as you
see fit :)

New RTT 2.0 namespace and directory structure

On Thu, Jun 18, 2009 at 19:42, Leopold
Palomo-Avellaneda<leopold [dot] palomo [..] ...> wrote:
> Well,
>
> it seems that I'm the only one that I have not understood it. So, if we have
> 2.x.y where 2 is the major, x is the minor and y is the patch level. Peter,
> please could you confirm:
>
> _always_ backwards compatibility is always guaranteed between 2.x.y and
> 2.x.z.  so you in patch level you have backwards compatibility. So, do you
> have binary compatibility and it's not necessary to recompile?

Yes, absolute binary compatibility like in the RTT 1.x versions for
the complete library. No visible class will change in an binary
incompatible way.

>
> BC -> Backwards Compatibility guaranteed between 2.x.0 and 2.y.0.
> Your code will compile betwend two different minor versions. Probably you will
> need recompile.

Yes. the SO version is '2.0' so '2.0' is binary incompatible with
'2.1', but we keep source compatibility for the sake of keeping users.

>
> NBC -> No backwards compatibility between two different minor versions. Your
> code is broken with the new version.

'Might be broken'. Say there is a class 'rtt/internal/Foo.hpp'.It
might disappear from 2.0 to 2.1, but in such a way that RTT 2.0 will
still be source compatible with 2.1. So if rtt/Bar.hpp inherits from
rtt/internal/Foo.hpp, Foo might disappear or change name between 2.0
and 2.1 and no user should have in his code RTT::internal::Foo* foo =
..., unless he's willing to carry the consequences. Users only using
RTT::Bar* bar = ... will always be on the safe side.

In order to limit the possible damage of such changes, we will take
care to have as little as possible headers in src/internal/ to be
installed in rtt/internal. (So the source tree's internal/ contains 50
headers and the installed internal/ contains only 10).

>
> What about compatibility to 1.x.y?

We will provide scripts that convert your 1.x component to 2.x (as
much as possible).

Peter

New RTT 2.0 namespace and directory structure

A Dijous 18 Juny 2009, Peter Soetens va escriure:
> On Thu, Jun 18, 2009 at 19:42, Leopold
> > What about compatibility to 1.x.y?

[...]

> We will provide scripts that convert your 1.x component to 2.x (as
> much as possible).

Thanks Peter,

Leo

New RTT 2.0 namespace and directory structure

A Dijous 18 Juny 2009, Peter Soetens va escriure:
> As Sylvain suggested before, the RTT needs a cleaner directory
> structure. I propose one, you guys shoot at it. Ok ?
>
> I couldn't get this nicely formatted in an email, so I've put it in the
> wiki:
> http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup/director
>ies-and-namespace-rework
>
> We can discuss it here, or if you 'Add new comment', It will appear on
> the 'Talk' page of the wiki.
>
> It's very drafty, but I'm aiming for 'about 10' headers in rtt/*.hpp
> and the rest in subdirectories.
>

Please,

could you define a bit more the abbreviates of the BC and NBC, because I think
that it's not clear:

<Quote>
Abbrevs: (N)BC: (N)Backwards Compatibility guaranteed between 2.x.0 and 2.y.0.
Backwards compatibility is always guaranteed between 2.x.y and 2.x.z.
<Quote>

Regards,

Leo

New RTT 2.0 namespace and directory structure

A Dijous 18 Juny 2009, Leopold Palomo-Avellaneda va escriure:
> A Dijous 18 Juny 2009, Peter Soetens va escriure:
> > As Sylvain suggested before, the RTT needs a cleaner directory
> > structure. I propose one, you guys shoot at it. Ok ?
> >
> > I couldn't get this nicely formatted in an email, so I've put it in the
> > wiki:
> > http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup/direct
> >or ies-and-namespace-rework
> >
> > We can discuss it here, or if you 'Add new comment', It will appear on
> > the 'Talk' page of the wiki.
> >
> > It's very drafty, but I'm aiming for 'about 10' headers in rtt/*.hpp
> > and the rest in subdirectories.
>
> Please,
>
> could you define a bit more the abbreviates of the BC and NBC, because I
> think that it's not clear:
>
> <Quote>
> Abbrevs: (N)BC: (N)Backwards Compatibility guaranteed between 2.x.0 and
> 2.y.0. Backwards compatibility is always guaranteed between 2.x.y and
> 2.x.z. <Quote>
>
Well,

it seems that I'm the only one that I have not understood it. So, if we have
2.x.y where 2 is the major, x is the minor and y is the patch level. Peter,
please could you confirm:

_always_ backwards compatibility is always guaranteed between 2.x.y and
2.x.z. so you in patch level you have backwards compatibility. So, do you
have binary compatibility and it's not necessary to recompile?

BC -> Backwards Compatibility guaranteed between 2.x.0 and 2.y.0.
Your code will compile betwend two different minor versions. Probably you will
need recompile.

NBC -> No backwards compatibility between two different minor versions. Your
code is broken with the new version.

What about compatibility to 1.x.y?

Regards,

Leo