unprotected object - protected object - component ...

Just some ideas of mine about the strategy for building functionality
for Orocos. Remarks are very welcome.

Baseline 1:
  Orocos wants to be an infrastructure for _all_ kinds of
  robotics. That means, the whole spectrum from hard real time to
  internet robotics.

Baseline 2:
  Orocos is a bottom-up effort, focusing first on serving the Framework
  Builders, and later also the Application Builders, the Component
  Builders and the End Users

Baseline 3:
  Compile-time reconfigurability is a key feature. Making this as
  simple and transparent as possible is a key goal too.

Hence:
I suggest to try to make functionality available keeping the following
structure in mind:
- unprotected object: a class library, were method calls can access
  the data in an object directly.
- protected object: a class library, where data access can only happen
  through access method calls that implement mutual exclusion and
  other protected means of data access.
- component: same as the protected object, but now in component form.
  The difference being mainly that objects are for programmers,
  components for users. That means, among other things, that extra
  functionality such as persistence, feature browsing, discovery, etc.
  should be available.
- CORBA component: the same as above, but CORBA compliant.

The reason for this hierarchy is simple: allow the most efficient code
for people that know what their doing and can do it in a controlled
environment. (Such as the core of the recently released Orocos hard
real-time code.) And offer less efficient but more guaranteed code for
use in less controlled environments.

Secondly, having functionality in the above-mentioned hierarchical
structure should make compile-time configuration much easier, because
if functionality is available in a lower layer, it is also available
in the higher layers, and with exactly the same name and semantics.

We are currently trying to get these things done for the motion
control: in the core framework, everything is centrally synchronized
by events which means that different parts can (in some cases) safely
access shared variables, such that unprotected objects are fine.  An
application using this hard real-time core, however, will in general
not be able or willing to guarantee this synchronized access, and that
should then use the protected or component variants. Or simply
distributing the hard real-time core over a local network (which
is still part of the Framework Builders' job) needs protected access
methods.

Herman

-- 
K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://www.mech.kuleuven.ac.be/~bruyninc>  +32 16 322480