On Fri, 20 Aug 2010, Markus Klotzbuecher wrote:

> On Wed, Aug 18, 2010 at 10:46:22PM +0200, Peter Soetens wrote:
>> It's summer, and the sun's heating of the northern hemisphere is
>> causing spontaneous combustions all-around. It's no wonder that this
>> extremely flammable list can't escape it's destiny. So here it goes.
>> Although we're all proud of using a component-based framework in
>> robotics, we're not particularly fond of the word 'Component' when
>> we're coding. TaskContext isn't 'Component', orogen isn't 'compgen',
>> getPeer() isn't getComponent(), etc. We're avoiding it in a random
>> manner, and the reason for this is plain simple: it's too long and
>> overloaded. A Python has it's egg, a Ruby is a gem, Java comes in
>> beans .. what does Orocos have ?
>>
>> I'm proposing to name our entities 'Orocos ents'. What is an ent
>> really ? Just like their mythical counterparts, the talking and
>> walking trees[1], they form an eco-system. One ent can do a great
>> deal, but organize an entmoot, and you have the most powerful system
>> of systems around[2]. Maybe that's too much for you, and you'd rather
>> start with entlings, ents that are small and simple, and which offer a
>> lot to learn. But in the ent, everything is an ent, which is a nice
>> principle when it comes to supervision and composition.
>>
>> entgen (orogen), entcreate (roscreate clone) , RTT::Ent (TaskContext)
>> and the powerful entmoot (deployer next generation).
>>
>> If it's explained early on the home page/docs I don't think it will
>> confuse people any more or as much as TaskContext does, or the whole
>> collage of names we give things these days for that matter.
>>
>> Worth discussing ?
>
> I got on my flame proof suit so now I can say: I like the suggestion!
>
> - It replaces the rather square TaskContext with a happier name and
> gives RTT a mascot.

Replacing the name of an unfortunately named software entity doesn't make
it more fortunate! What we did wrong with TaskContext in RTT is that is a
"nice" example of too much coupling:
- it serves as a "container" component (it is the "platform runtime")
- it implements lots of "Communication" (between running components and the
operator's console, etc.)
- it provides "Services" (giving the operator access to the current status
of data etc.)
- it does some "Coordination" (start/stop stuff etc.)

So, which of the TaskContext's activities' renaming are we talking about?

> - It solves the endless oro vs. rtt prefix issue
By introducing a useless new name! As should be clear from my remarks
above, TaskContext is not pure "RTT", nor pure "Orocos", since it is a
runtime _implementation that supports (very well I must say) all Orocos
stuff, but in principle also the running application's internals.

> - Best practice naming is orthogonal to this. The term 'Component' is
> mostly understood. Adopting standardized naming will help solve the
> much greater confusion around the naming of primitives.
>
> - The coolness factor of "ent" is orders of magnitude higher than
> 'Component"

De gustibus coloribusque non est disputandum...

> +1

-10!

> :-)
>
> Markus

:-)

Herman

On Thu, Aug 19, 2010 at 12:10 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> On 08/18/2010 10:46 PM, Peter Soetens wrote:
>>
>> It's summer, and the sun's heating of the northern hemisphere is
>> causing spontaneous combustions all-around. It's no wonder that this
>> extremely flammable list can't escape it's destiny. So here it goes.
>> Although we're all proud of using a component-based framework in
>> robotics, we're not particularly fond of the word 'Component' when
>> we're coding. TaskContext isn't 'Component', orogen isn't 'compgen',
>> getPeer() isn't getComponent(), etc. We're avoiding it in a random
>> manner, and the reason for this is plain simple: it's too long and
>> overloaded. A Python has it's egg, a Ruby is a gem, Java comes in
>> beans .. what does Orocos have ?
>>
>> I'm proposing to name our entities 'Orocos ents'. What is an ent
>> really ? Just like their mythical counterparts, the talking and
>> walking trees[1], they form an eco-system. One ent can do a great
>> deal, but organize an entmoot, and you have the most powerful system
>> of systems around[2]. Maybe that's too much for you, and you'd rather
>> start with entlings, ents that are small and simple, and which offer a
>> lot to learn. But in the ent, everything is an ent, which is a nice
>> principle when it comes to supervision and composition.
>>
>> entgen (orogen), entcreate (roscreate clone) , RTT::Ent (TaskContext)
>> and the powerful entmoot (deployer next generation).
>>
>> If it's explained early on the home page/docs I don't think it will
>> confuse people any more or as much as TaskContext does, or the whole
>> collage of names we give things these days for that matter.
>>
>> Worth discussing ?
>> Peter
>>
>> [1] http://en.wikipedia.org/wiki/Ent
>> [2] Ents destroyed the war machine of Isengard, but can handle the
>> wizard of rOZ too.
>>
>
> I originally thought that it was a joke, but it seems that it is not ... So
> I'll jump in.

I thought it was funny too. Even more, my first idea was to call them
'forks' (Hey, I created this new fork..etc.), but I'm glad now that I
didn't go that road. I clearly underestimated my weight on this list
and I'll consider alternative methods to brainstorm about the future
of this project.

>
> I personally think that it is becoming more important that we get some
> software out there instead of bike-shedding the naming of things. RTT2 was
> supposed to be beginning of *this* year. Not the next.
>
> Especially if it is renaming TaskContext which is hardly where -- I
> personally believe -- there is a problem. As long as you explain to people
> TaskContext == Component, they're fine with it.

Ok, I'll just keep it for my next pet project.

>
> In other words, your proposal does not address the biggest naming problem
> (operations and services).

Serious now, that's ironic, since both *are* renames to solve issues
with RTT 1.x's Command/Method and TaskObject primitives. The planned
list of 2.0 changes was decided on the -dev meeting, related to
operations and services, only 'Method/ServiceProvider' were on the
agenda and have been resolved. I'm a bit surprised that this statement
is seconded...

Peter

> In other words, your proposal does not address the biggest naming
> problem (operations and services).

+1

On Thu, Aug 19, 2010 at 5:15 AM, Herman Bruyninckx
<Herman [dot] Bruyninckx [..] ...> wrote:
> On Wed, 18 Aug 2010, Peter Soetens wrote:
>> It's summer, and the sun's heating of the northern hemisphere is
>> causing spontaneous combustions all-around. It's no wonder that this
>> extremely flammable list can't escape it's destiny. So here it goes.
>> Although we're all proud of using a component-based framework in
>> robotics, we're not particularly fond of the word 'Component' when
>> we're coding. TaskContext isn't 'Component', orogen isn't 'compgen',
>> getPeer() isn't getComponent(), etc. We're avoiding it in a random
>> manner, and the reason for this is plain simple: it's too long and
>> overloaded. A Python has it's egg, a Ruby is a gem, Java comes in
>> beans .. what does Orocos have ?
>>
>> I'm proposing to name our entities 'Orocos ents'. What is an ent
>> really ? Just like their mythical counterparts, the talking and
>> walking trees[1], they form an eco-system. One ent can do a great
>> deal, but organize an entmoot, and you have the most powerful system
>> of systems around[2]. Maybe that's too much for you, and you'd rather
>> start with entlings, ents that are small and simple, and which offer a
>> lot to learn. But in the ent, everything is an ent, which is a nice
>> principle when it comes to supervision and composition.
>>
>> entgen (orogen), entcreate (roscreate clone) , RTT::Ent (TaskContext)
>> and the powerful entmoot (deployer next generation).
>>
>> If it's explained early on the home page/docs I don't think it will
>> confuse people any more or as much as TaskContext does, or the whole
>> collage of names we give things these days for that matter.
>>
>> Worth discussing ?
>
> Yes, of course.
>
> My contributions to the discussions:
> - the argument that something is too long to write down is of secondary,
>   even tertiary importance, especially with the fine word completion
>   functionalities in all decent editors and IDEs.
> - if "Component" is overloaded, then we should explain what our meaning of
>   the word is, and not invent another name; that does not make the
>   explanation job any easier. On the contrary: we will have to explain
>   why and how our "thing" is different from the "components" in other
>   frameworks.
> - on this context, I am advocating to reuse an already existing framework's
>   definition, in order to save efforts in explaining the meaning of the
>   word to our users and developers. SCA (Service Component Architecture)
>   of OASIS
>     <http://www.osoa.org/display/Main/Service+Component+Architecture+Home>
>   fits very well. At least for the structural parts of component-based
>   programming.
>
> Introducing yet another name is not "best practice"!

For once, I fully agree with Herman :-)

k
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

On Thu, Aug 19, 2010 at 12:00 AM, Geoffrey Biggs
<geoffrey [dot] biggs [..] ....j

wrote:
> On 19/08/10 05:46, Peter Soetens wrote:
...
>>
>> I'm proposing to name our entities 'Orocos ents'. What is an ent
>> really ? Just like their mythical counterparts, the talking and
>> walking trees[1], they form an eco-system. One ent can do a great
>> deal, but organize an entmoot, and you have the most powerful system
>> of systems around[2]. Maybe that's too much for you, and you'd rather
>> start with entlings, ents that are small and simple, and which offer a
>> lot to learn. But in the ent, everything is an ent, which is a nice
>> principle when it comes to supervision and composition.
>>
>> entgen (orogen), entcreate (roscreate clone) , RTT::Ent (TaskContext)
>> and the powerful entmoot (deployer next generation).
>>
>> If it's explained early on the home page/docs I don't think it will
>> confuse people any more or as much as TaskContext does, or the whole
>> collage of names we give things these days for that matter.
>>
>> Worth discussing ?
>
> Whether or not "ent" is the right solution, I do think that Orocos has a
> problem with naming. It's definitely worth discussing.
>
> What would you call a network of ents?

It would be an ent in return, wouldn't it ? But I'm betting on it you want me to
say an 'entwork' :-)

Peter

On Thu, Aug 19, 2010 at 00:00, Geoffrey Biggs <geoffrey [dot] biggs [..] ....j

wrote:
> On 19/08/10 05:46, Peter Soetens wrote:
>> It's summer, and the sun's heating of the northern hemisphere is
>> causing spontaneous combustions all-around. It's no wonder that this
>> extremely flammable list can't escape it's destiny. So here it goes.
>> Although we're all proud of using a component-based framework in
>> robotics, we're not particularly fond of the word 'Component' when
>> we're coding. TaskContext isn't 'Component', orogen isn't 'compgen',
>> getPeer() isn't getComponent(), etc. We're avoiding it in a random
>> manner, and the reason for this is plain simple: it's too long and
>> overloaded. A Python has it's egg, a Ruby is a gem, Java comes in
>> beans .. what does Orocos have ?
>>
>> I'm proposing to name our entities 'Orocos ents'. What is an ent
>> really ? Just like their mythical counterparts, the talking and
>> walking trees[1], they form an eco-system. One ent can do a great
>> deal, but organize an entmoot, and you have the most powerful system
>> of systems around[2]. Maybe that's too much for you, and you'd rather
>> start with entlings, ents that are small and simple, and which offer a
>> lot to learn. But in the ent, everything is an ent, which is a nice
>> principle when it comes to supervision and composition.
>>
>> entgen (orogen), entcreate (roscreate clone) , RTT::Ent (TaskContext)
>> and the powerful entmoot (deployer next generation).
>>
>> If it's explained early on the home page/docs I don't think it will
>> confuse people any more or as much as TaskContext does, or the whole
>> collage of names we give things these days for that matter.
>>
>> Worth discussing ?
>
> Whether or not "ent" is the right solution, I do think that Orocos has a
> problem with naming. It's definitely worth discussing.
>
> What would you call a network of ents?
>
> Geoff
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

That would be an entmoot.

http://encyclopedia.thefreedictionary.com/Ent+(fiction)

-H