[Core] Components design

Anthony Mallet <[email protected]>
Newsgroups gmane.science.robotics.orocos.user
Organization LAAS (CNRS) - Toulouse - France
Message-ID <[email protected]>
Hi!

Now that we're officially "kicked off", I fell like I cannot wait anymore
to start concrete discussions about what we'll do within Orocos :)

The meeting was great, with many interesting presentations and
discussions. In my opinion, we share the very same objectives, and the
discussions showed that we all want to achieve some true collaborative
work. Maybe the meeting was not the hardest task but it's still a
very positive experience for me :)
I hope it was the same for all participants!

With this mail, I want to start discussions about two things that
appear very interdependent to me (although they have to be decoupled, the
design of one should take into account the design of the other):

1. "components" (or modules) design (this goes into WP 1)
2. communication between components (WP 2.6)

Since it's the first concrete action on these work packages, I will stay
at a very general level :)


1. Module design

Something on which we should agree is: what's a module?
We can start with this very general and incomplete definition:

"a component is a black box, that will offer services to other
components. The services are actually algorithms that are grouped within
the same module because they provide to the rest of the system the
necessary functions to access or control a given physical or logical
resource".


The first observation I can make regarding the modules design is
that we will need to agree on a formal description of the services
offered by the various components we'll want.
This description should include all the necessary information needed to
invoke the set of services of the components. It should also be generic
enough to fit in the requirements of every module (ranging from
rtlinux in-kernel tasks to any-time userland processes).

To help focusing ideas on that description, I propose to set up a
working document. I will disseminate a first draft within a couple of
weeks ("soft real-time" ;).


2. Comms

The communication library we will design will have at least two main
goals: to exchange data between components and to trigger the execution
of the services.
Since the architectures we'll want to address range from hard real time
to any time ones, I feel like it will be hard to come up with one,
generic, universal library. Also we should be able to define several
comms libraries and make them inter-operable (corba or rpc or ...).

To achieve this, we'll have to specify the messaging format. And not only
the structure of the messages but also the "protocol" we'll want. For
instance, a client server protocol, with the notion of "request",
"acknowledgment", and "reply". 
Again, this is only *one particular* vision of the comms and everyone
should tell what is its vision, requirements, and so on...


I stop there for now, this mail is already too long :)
Comments wanted!
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.