Re: My 2c

On Thu, 9 Aug 2001, David Austin wrote:

>
> Here are my thoughts on Orocos (as it stands today):
Thanks.

This paragraph is written after I've carefully read your whole email: I
strongly believe we are thinking along very compatible lines. To
summarize: my idea of what Orocos should become is, in the first
place, a set of robotics _libraries_ of high quality, and, only in the
second place, a reference architecture (or rather, a _set_ of possible
reference architectures, because I don't believe that there is only
one superior design). Both things (libraries and designs) have to be
as decoupled as possible: whatever architecture you want to use for
your system you should be able to construct it out of Orocos (and
other) building blocks for more than 90%. And the issues you mention
(CORBA and XML) should only be means to _glue_ things together, and
not key factors in the _contents_ of Orocos.

Now about the more detailed discussion:

[...]
> My biggest problems are with CORBA and XML:

If these are your problems then there are no problems at all :-) Why?
Because the CORBA thing is nothing but glue that _can_ be used to
connect things. Nothing in the orocos code should depend on CORBA if
you don't want to use it. For example, our own interests are in force
control, and I would not even think of using CORBA in such
time-critical applications.

But `higher-level' users and companies will want use Orocos (and
other) code, and integrate it. (I hope.) I just have another (Belgian)
open source project approved, in which three machine tool companies
are involved: they have explicitly expressed their interest in
standard communication protocols and tools such as CORBA and XML; so I
know these things matter, albeit not directly at the core of Orocos.

>  1) I don't think that it has reached maturity and become a widely
>     accepted standard
I agree with you. But doesn't the same hold for alternatives?

>  2) I don't think that it will ever reach the real-time performance
>     that we desire for the low-level control
Of course. As I said earlier, CORBA is no option for these
applications. Apparently, what is on the web is not sufficiently clear
in this respect, so I will have to change it :-)

>  3) While the standard is portable and can in theory be used on any
>     software platform, reality is a little different.  CORBA would be
>     another *major* software component to install on every computer in
>     the lab

I agree.

>  4) It is a complex, abstract system that every PhD student would have
>     to learn

I agree.

But I do see some useful applications for CORBA (or SOAP, or...), at
higher, less time-critical and machine-dependent levels. For example:
I want to test your motion planner on my system, or you want to
compare my pattern recognition algorithm with yours, etc.


> XML: I think that XML is a total waste of time.  There are many
> portable messaging schemes and the only difference with XML is that it
> wastes more bandwith than all the others by using [almost]
> human-readable messages. Note that whatever encoding scheme one uses,
> it is still necessary to have knowledge of the semantics at both the
> sender and the receiver.  XML doesn't help with this and it is hugely
> wasteful of bandwidth.  XML is just the latest fancy buzzword that
> managers like to use - there have been solutions to this problem for
> decades! (see http://www.eetimes.com/story/OEG20010807S0038)

I am open to any alternative! But I really believe the value of having
a real standard, mainly because of :
1. the _tools_ that exist for it.
2. the familiarity of the average Linux programmer with the concepts
   and tools of XML. For example, XML in more and more in the core of
   popular projects such as Gnome, which guarantees us the
   availability of up-to-date and featureful software to deal with XML.

Which other alternative has this wide support?  Of course it spoils
bandwidth, so (as for CORBA) no part of the software should use it in
time-critical situations. For example: I don't want my servo thread
talk to the sensors in XML :-)

And of course there  have been solutions to this problem for ages, but
which of them is better, and why? This ASN.1 that you mention? Who is
going to use that? What tools exist?

Just to be sure: XML is (as all other things in Orocos) not a
breakpoint for me!

> To facilitate coding by PhD students, we need to provide a system for
> modular software development.  So, we need basic systems for
> communication (using a variety of methods) and execution of processes
> (across a number of CPUs).

I agree.

>  Another issue that I believe is important
> (though, more a matter of management than technology) is that the
> interfaces between modules need to be well defined and change as
> little as possible.

I agree, and that's exactly the only reason why I tried to manage
Orocos in a way that might be a-typical for open source: first talk
about design (and interfaces is the essence of design), and only then
start coding (or wrapping existing code).
Though, of course, that's easier said than done :-)

> I will be attending the meeting at the start of September so we can
> continue this discussion over a beer or two. :-)
Great! But I'll leave the beer drinking to you, and take a glass of
wine, if you don't mind :-)

See you!

Herman