I'm worried....

There has been a lot of activity on this mailing list the last couple of
weeks, thanks to our "kiwi users", and this is _very much_ appreciated.
However, I want to raise a concern, and to discuss its repercussions....

The discussion about the FSM and scripting functionalities in Orocos seem
to be going in the direction of extending the current scripting
functionality towards making it a full fledged application programming
language. That has never been the purporse, and I would still not really
like to see things evolve in this direction!

The problem I see is that introducing application extensions into something
that was initially meant to be only something to support discrete event
handling in a "user friendly" way introduces the risk of coupling things
too much!

I would prefer to see all application-specific functionalities in an
application-specific language, and keep the scripting free from those
application specifics. (Orocos _has_ support for application languages, but
is has not been used very much...) For example, _every_
application-specific data flow should take place via data ports between
components, while the FSM should just support the deterministic execution
of state transitions within components.

Another result of the ongoing discussion is that the semantics of our FSM
support is not well defined. We knew this already, but we knew also already
that "fixing" it should be done in a more thoughtful way than "just" bug
fixing. I will have a new PhD student, starting "really soon now", whose
first project will exactly be this: seriously refactoring the FSM
functionality in Orocos, in order to (i) get its semantics clear, and (ii)
make it compatible with the state charts and activity diagrams of
UML2/SysML.

So in summary, while I do like the boost that RTT got from the ongoing
interest, I think we should be _very_ careful not to begin coupling things
that do not belong together.

Herman

I'm worried....

On Saturday 31 May 2008 15:23:19 Herman Bruyninckx wrote:
> There has been a lot of activity on this mailing list the last couple of
> weeks, thanks to our "kiwi users", and this is _very much_ appreciated.
> However, I want to raise a concern, and to discuss its repercussions....
>
> The discussion about the FSM and scripting functionalities in Orocos seem
> to be going in the direction of extending the current scripting
> functionality towards making it a full fledged application programming
> language. That has never been the purporse, and I would still not really
> like to see things evolve in this direction!

As Stephen pointed out, we're only fixing bugs at the moment and not adding
new features. Yes, it's sometimes a thin line we're walking, especially if
semantics are getting a closer look. But we're nowhere near adding
application specific constructs...

>
> The problem I see is that introducing application extensions into something
> that was initially meant to be only something to support discrete event
> handling in a "user friendly" way introduces the risk of coupling things
> too much!

If you have a concrete example which led to this belief...

>
> I would prefer to see all application-specific functionalities in an
> application-specific language, and keep the scripting free from those
> application specifics. (Orocos _has_ support for application languages, but
> is has not been used very much...) For example, _every_
> application-specific data flow should take place via data ports between
> components, while the FSM should just support the deterministic execution
> of state transitions within components.

That's how 'we' all work. I don't undertand the 'Orocos _has_ support for
application languages, but this has not been used very much...' mantra.

>
> Another result of the ongoing discussion is that the semantics of our FSM
> support is not well defined. We knew this already, but we knew also already
> that "fixing" it should be done in a more thoughtful way than "just" bug
> fixing. I will have a new PhD student, starting "really soon now", whose
> first project will exactly be this: seriously refactoring the FSM
> functionality in Orocos, in order to (i) get its semantics clear, and (ii)
> make it compatible with the state charts and activity diagrams of
> UML2/SysML.
>
> So in summary, while I do like the boost that RTT got from the ongoing
> interest, I think we should be _very_ careful not to begin coupling things
> that do not belong together.

The RTT is so application-unspecific that I see it more as a disadvantage for
early adoptation than an advantage. Imagine if Drupal was only a library for
making a CMS instead of a CMS itself... It would have been just another PHP
library. That brings us to the RTT vs OCL separation. No-one is using the RTT
without at least some components of the OCL (taskbrowser, deployer,...) If
this coupling is daily practice, I wonder why we're separating it then...

Peter

I'm worried....

On Mon, 2 Jun 2008, Peter Soetens wrote:

[...]
>> The problem I see is that introducing application extensions into something
>> that was initially meant to be only something to support discrete event
>> handling in a "user friendly" way introduces the risk of coupling things
>> too much!
>
> If you have a concrete example which led to this belief...
>
I was just expressing my worries that this _could_ happen. Proactively :-)

>> I would prefer to see all application-specific functionalities in an
>> application-specific language, and keep the scripting free from those
>> application specifics. (Orocos _has_ support for application languages, but
>> is has not been used very much...) For example, _every_
>> application-specific data flow should take place via data ports between
>> components, while the FSM should just support the deterministic execution
>> of state transitions within components.
>
> That's how 'we' all work. I don't undertand the 'Orocos _has_ support for
> application languages, but this has not been used very much...' mantra.
>
You have implemented yourself the support for a "language parser", but, as
far as I know, no such languages have been implemented yet. Which is a
pity, I think. (See below.)

[...]
>> So in summary, while I do like the boost that RTT got from the ongoing
>> interest, I think we should be _very_ careful not to begin coupling things
>> that do not belong together.
>
> The RTT is so application-unspecific that I see it more as a disadvantage for
> early adoptation than an advantage.
I agree. That's why the OCL (and "GUI" and "language") activities are so
important... We have not spent much time in making the user experience
easier, because we have been working so much on the framework level. I am
not blaming anybody, because resources have been scarce.

Herman

I'm worried....

On May 31, 2008, at 09:23 , Herman Bruyninckx wrote:

> There has been a lot of activity on this mailing list the last
> couple of
> weeks, thanks to our "kiwi users", and this is _very much_
> appreciated.
> However, I want to raise a concern, and to discuss its
> repercussions....
>
> The discussion about the FSM and scripting functionalities in Orocos
> seem
> to be going in the direction of extending the current scripting
> functionality towards making it a full fledged application programming
> language. That has never been the purporse, and I would still not
> really
> like to see things evolve in this direction!

In reality, we're not planning on using the scripting functionality
much. We are currently just using it as a rapid prototyping approach
to testing ideas, that will then be put into the application language
(C++, presuming that this is what you mean by application language?)
and attached to a GUI. The only post I've done on the scripting
language is I believe a bug, certainly not a feature request (it
appears that one data type doesn't work like the others).

State machines are a different story (more on that below).

> The problem I see is that introducing application extensions into
> something
> that was initially meant to be only something to support discrete
> event
> handling in a "user friendly" way introduces the risk of coupling
> things
> too much!
>
> I would prefer to see all application-specific functionalities in an
> application-specific language, and keep the scripting free from those
> application specifics. (Orocos _has_ support for application
> languages, but
> is has not been used very much...) For example, _every_
> application-specific data flow should take place via data ports
> between
> components, while the FSM should just support the deterministic
> execution
> of state transitions within components.

Your last statement here has been the guiding principle to date on how
we've been structuring our system. Data flows between our components
using data ports. State machines control the behaviour of components,
with a small amount of event propogation between state machines to
control system-wide behaviour. The component can affect its own state
machine, which has been the cause of numerous recent posts on the
state machine implementation. Our control-source component ("HMI" in
Orocos' examples, basically what the user interacts with) is the only
one with any scripting attached to it, and that is for only for
prototyping (and is already migrating some of it into C++ inside the
component).

Based on this, I'm really not understanding your concept of
"application-specific functionalities" and this "coupling" you are
worried about. Can you be more descriptive please? We would like to
understand so that we can have a more productive dialog.

> Another result of the ongoing discussion is that the semantics of
> our FSM
> support is not well defined. We knew this already, but we knew also
> already
> that "fixing" it should be done in a more thoughtful way than "just"
> bug
> fixing. I will have a new PhD student, starting "really soon now",
> whose
> first project will exactly be this: seriously refactoring the FSM
> functionality in Orocos, in order to (i) get its semantics clear,
> and (ii)
> make it compatible with the state charts and activity diagrams of
> UML2/SysML.

We have defintely been trying to use the RTT state machines in a UML
fashion. They don't support this, and we know that. Our ongoing
discussions on this with Peter have most recently revolved around
exactly this topic: when do we stop "improving" the current
implementation? Some of the recent fixes have been corrective, while
some are more perfective in nature. Peter has already helped us
overcome the basic problems, and we're very close to the point now (I
think, Peter correct me if I'm wrong) of stopping and waiting for this
"v2.0 push" to get state machines to be (more) UML-compliant. I think
we are already tackling the very concern you've bought up, though
maybe from a slightly different point of view is all.

> So in summary, while I do like the boost that RTT got from the ongoing
> interest, I think we should be _very_ careful not to begin coupling
> things
> that do not belong together.

Underneath all this disucssion I think one of the real questions to
ask is this: where are _you_ (plural, the steering committee
essentially) taking this open source project? One of my initial posts
was questioning on the missing roadmap. Will the forthcoming v1.6 be
just bug fixes? What might be in v2.0? When might v2.0 be out? Is v2.0
likely to be evolutionary, or more revolutionary?

Without this knowledge, those of us just joining the project, or those
considering using the project, have no idea of what is coming down the
pipeline and no idea of when (which is obviously a somewhat vague
concept anyway). This would help us make informed decisions, and also,
I believe, help the community become involved by being able to decide
where and when we can each pitch in. We are happy to help after all! :-)

What are the thoughts of the rest of the community?

Cheers
A Kiwi User

I'm worried....

On Sunday 01 June 2008 19:19:02 S Roderick wrote:
>
> Underneath all this disucssion I think one of the real questions to
> ask is this: where are _you_ (plural, the steering committee
> essentially) taking this open source project? One of my initial posts
> was questioning on the missing roadmap. Will the forthcoming v1.6 be
> just bug fixes? What might be in v2.0? When might v2.0 be out? Is v2.0
> likely to be evolutionary, or more revolutionary?

I have to line up with Herman here. If I was still doing my PhD, I had dared
to write out such a roadmap and fiercefully try to obey it. Today, with
having about 1/12 of the effort available as compared to then, we're clearly
in an 'increment-only' mode instead of 'revolutionary'. Although your
definition of revolutionairy might differ from mine. I'd be happy to release
2.0 when it has evolved in something quite different from our (good) old 1.0
release. The only difference between 2.0 and say, 1.12, would be the removal
of deprecated features. Users would have had 'long' time to adapt to the new
API / scripting syntax / GUI :-)

>
> Without this knowledge, those of us just joining the project, or those
> considering using the project, have no idea of what is coming down the
> pipeline and no idea of when (which is obviously a somewhat vague
> concept anyway). This would help us make informed decisions, and also,
> I believe, help the community become involved by being able to decide
> where and when we can each pitch in. We are happy to help after all! :-)

With my current track record of letting deadlines slip for 2 months or more,
I'm not sure I'm doing myself/users a favor of pinning dates. For now,
submitting as Bugzilla 'Project' items is still the best maintainable way,
but not very easy to read/find by users... something better is on the roadmap
as well :-/

Peter

I'm worried....

On Sun, 1 Jun 2008, S Roderick wrote:

[...]
> Based on this, I'm really not understanding your concept of
> "application-specific functionalities" and this "coupling" you are worried
> about. Can you be more descriptive please? We would like to understand so
> that we can have a more productive dialog.

What I wanted to say is that I would not like to see any
application-specific stuff in RTT, nothing more :-)

>> Another result of the ongoing discussion is that the semantics of our FSM
>> support is not well defined. We knew this already, but we knew also already
>> that "fixing" it should be done in a more thoughtful way than "just" bug
>> fixing. I will have a new PhD student, starting "really soon now", whose
>> first project will exactly be this: seriously refactoring the FSM
>> functionality in Orocos, in order to (i) get its semantics clear, and (ii)
>> make it compatible with the state charts and activity diagrams of
>> UML2/SysML.
>
> We have defintely been trying to use the RTT state machines in a UML fashion.
> They don't support this, and we know that. Our ongoing discussions on this
> with Peter have most recently revolved around exactly this topic: when do we
> stop "improving" the current implementation? Some of the recent fixes have
> been corrective, while some are more perfective in nature. Peter has already
> helped us overcome the basic problems, and we're very close to the point now
> (I think, Peter correct me if I'm wrong) of stopping and waiting for this
> "v2.0 push" to get state machines to be (more) UML-compliant. I think we are
> already tackling the very concern you've bought up, though maybe from a
> slightly different point of view is all.

Good to hear! :-)

>> So in summary, while I do like the boost that RTT got from the ongoing
>> interest, I think we should be _very_ careful not to begin coupling things
>> that do not belong together.
>
> Underneath all this disucssion I think one of the real questions to ask is
> this: where are _you_ (plural, the steering committee essentially) taking
> this open source project?

It's an open source project, so basically developments are driven by
available man power. Standards compliance is on _my_ roadmap, and that
roadmap will have hopefully some manpower available in the coming months...

> One of my initial posts was questioning on the
> missing roadmap. Will the forthcoming v1.6 be just bug fixes? What might be
> in v2.0? When might v2.0 be out? Is v2.0 likely to be evolutionary, or more
> revolutionary?
By definition, a new major number should indicate "revolution" :-)

> Without this knowledge, those of us just joining the project, or those
> considering using the project, have no idea of what is coming down the
> pipeline and no idea of when (which is obviously a somewhat vague concept
> anyway). This would help us make informed decisions, and also, I believe,
> help the community become involved by being able to decide where and when we
> can each pitch in. We are happy to help after all! :-)

As I said already: (contributing) users define the roadmap... :-)
The largest set of these is "hidden" behind the industrial FMTC projects
around Orocos, so Peter and/or Klaas could maybe give some indications...?

Herman (representing the K.U.Leuven robotics users)