Re: Deva, as library

[Marcus Brinkmann]

At Thu, 20 Jan 2005 17:56:09 -0600,
markus kaarn <address@hidden> wrote:
>  From what i've seen on here (address@hidden), there was suggestion
> to treat/implement Deva as a library. What i can say here - this is not 
> serious.

I think you have the wrong mental picture of a "library".

A library is nothing but a set of shared object files that is linked
together with other object files to form an executable program.

If we say "deva can be a library" we are saying that deva will share
its address space with some components of the ddf, rather than being a
stand alone executable program that communicates with the ddf solely
through inter process communication.

There is a priori _no_ semantical change by this.  In particular:

> the Deva is interface between _all-drivers-space_(PLMs), and the rest of 
> the system.

... would still be true.

> So, if you want to implement Deva as library, this means one can access 
> this "all-drivers-space"
> directly, even without using libDeva by writing algorithms in its own code.

False.

> If you think of Deva as of a library, not some system service, then Deva 
> lost it's point here.

A system service can be implemented as a library.

However, I would be happy with a small change, by saying that the
"ddf" will be a "library" used by "deva".  Note that I can say this
without actually meaning to change anything semantically.

The only reason I would prefer wording it this way is to make clear
that the actual "exec" protocol (initial stack layout etc) should be
defined by deva, not by the ddf.

> p.s wasn't from beginning Deva was supposed to be a server?

Yes, and still is, even if it is linked together with fabrica.

To make it absolutely sure: The only thing that was discussed is if
deva and the ddf should/must use an RPC interface or can use a normal
function call interface (which is more efficient, but makes separation
harder).

The killer argument for me here is that you can always go from a
function call interface to an RPC interface by writing RPC stubs for
the function call implementations.  Going the other way seems to be
close to impossible (unless you do some funny things that make the
distinction meaningless).

Thanks,
Marcus