A nice idea (for a flame war)

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.

A nice idea (for a flame war)

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.

- It solves the endless oro vs. rtt prefix issue

- 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"

+1

:-)

Markus

A nice idea (for a flame war)

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

A nice idea (for a flame war)

On Fri, Aug 20, 2010 at 01:11:59PM +0200, Herman Bruyninckx wrote:
> On Fri, 20 Aug 2010, Markus Klotzbuecher wrote:
...

> > +1
>
> -10!

I forgot to appreciate this interesting case of "weighted democracy" :

:-)

Markus

A nice idea (for a flame war)

On Fri, Aug 20, 2010 at 01:11:59PM +0200, Herman Bruyninckx wrote:
> 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?

All of them! All you need to compile, deploy and run an Ent.

> > - 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

A nice idea (for a flame war)

On Fri, 20 Aug 2010, Markus Klotzbuecher wrote:

> On Fri, Aug 20, 2010 at 01:11:59PM +0200, Herman Bruyninckx wrote:
>> 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?
>
> All of them! All you need to compile, deploy and run an Ent.

This answer only corroborates my claim that the TaskContext is doing too
much...

Herman

>
>>> - 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
>

--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>

A nice idea (for a flame war)

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 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.

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

A nice idea (for a flame war)

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

A nice idea (for a flame war)

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

+1

A nice idea (for a flame war)

On Aug 19, 2010, at 06:39 , Hugo Garcia wrote:

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

+1

IIRC beginning of 2010 .... not 2011 ... 2012 ....
S

A nice idea (for a flame war)

On Wed, Aug 18, 2010 at 22:46, Peter Soetens <peter [..] ...> 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.
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

I propose a chocolate based naming system:

A component could be Praline.

http://nl.wikipedia.org/wiki/Praline

-H

A nice idea (for a flame war)

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"!

Herman

A nice idea (for a flame war)

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

A nice idea (for a flame war)

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

A nice idea (for a flame war)

On Thu, Aug 19, 2010 at 12:00 AM, Geoffrey Biggs
<geoffrey [dot] biggs [..] ...> 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

A nice idea (for a flame war)

On Thu, Aug 19, 2010 at 00:00, Geoffrey Biggs <geoffrey [dot] biggs [..] ...> 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