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

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