Re: division in sub projects (or not ?)

On Friday 14 December 2001 16:04, you wrote:
<snip>
>
> | For "inter-component" communication / linking, we will use an "Orocos
> | Wrapper Interface" (ORWIN :-) )  If you want to use a particular system
> | call or a  method of another component, you'll have to write a wrapper
> | from ORWIN to your Operating System, Module or Component.
>
> We are currently working on a strong decoupling between 'functionalities'
> and the 'underlying system' (if you can wait a few hours I should be able
> to release a document which would explain further this idea).

Great ! I'll be waiting eagerly :-)

>
> 'underlying system' comprises all communication functions. I think we
> should be able to use several such systems, 

Well, RTAI for example has a distributed communication infrastructure. But we 
could also use a realtime CORBA implementation.  Orocos should not be biased 
towards any of these systems. Finding a good common interface (== identifying 
which functionality we need exactly ) won't be easy to solve.

But if components are to be truely context independent, we need to enforce 
this way of doing things anyway.  I hope to find a lot of expertise in the 
component based software research, since we don't have the knowledge here.

> which would not necessarily
> use the same interface. I'm not so sure that  wrappers can do
> everything. And furthermore this often adds an overhead which might not
> be desirable all the time.
>
> Besides this, ORWIN sounds great :)
>
> | The selection of appropriate wrapper /module / component should be done
> | by a "Configuration Agent" whose sole purpose is to combine hot spots
> | with frozen spots and thus complete the framework (see glossary
> | http://www.orocos.org/glossary.html ).
>
> Do you think of an 'interface' that would lauch the necessary things in
> the right order, or is it something else ?

I see two kind of configuration agents : one during compile time and one 
during run time.  Since we don't want to fix what is kernel / userspace, used 
OS,... thus leaving the architecture open, we need a 'manager' that interacts 
with the developper which then can chose/design architecture and component 
choices.  Think of it like the linux kernel 'make menuconfig' script. 
On the other hand, the runtime Supervisor can then again configure the system 
but will have less degrees of freedom since some matters will have been fixed 
during compile time (like the OS it is running on).

greets,
Peter