IPC in the current OO model

[Anders Petersson]

>From: Pieter Dumon <Pieter.Dumon@rug.ac.be> (in unios@onelist.com)
>> From: Tril <dem@tunes.org>
>> 
>> > As I understand the current OO model each object has a set
>> > of methods that are accessed over the IPC channels. Correct?
>> > 
>> > I can only come up with two ways of doing this:
>> > 
>> > 1: Interpret method tokens
>> > 
>> > 2: Setup a communication channel for each and every method.
>> > This would involve a system with thousands of open
>> > communication channels. The overhead would be monstrous!
>> > 
>> > If someone can come up with another solution, do tell!
>
>This is not the case. The interfaces to handle objects can be in the
>"executable" object as shared libraries or something. (If you are used to
>Winblows, DLLs). Lots of common OH's can be too. Other OH's are executed
>by some central  database which connects object types to OHs.
>Some OHs will indeed be seperate threads or processes, which requires IPC
>to call.

Several OHs can be implemented by one module, yes. But there is no need for
a database to do so, the systree already has many database features.
I don't think OHs can be embedded in applications... unless the application
in question is indeed the rightful manager of the object type. But having
common OH's in applications for performance reasons isn't good.

Speaking about databases... do you think it would be useful to handle
SQL-like queries to the systree, and how would that be managed and presented?

>> There is a third solution, that is used by the TUNES project: 
>> Metaprogramming.  To perform an action, the objects are first strongly
>> type-checked, then linked directly together.  Since they have already been
>> typechecked, they can be treated as one composite object.  The
>> specification (we prefer that term to 'code' because a specification is
>> not in ASCII format, but made of objects) for the two together can be
>> optimized.  We believe this solution is both fast AND safe.
>
>It would be safe if it would work.... But it won't. 

And, that requires another definition of objects than the one in mOS. mOS'
objects can't be linked together. And you don't type-check the objects either.

What you *want* to do is to have a way to transfer objects between
communicating objects - for example a string. In some way the interface has
to define the desired objects, and objects of those types are moved from
being children of the calling object to being children of the other object.
No memory transfers of the actual strings are needed - the data is safe in
the data space of the OH, and only the ownership information is changed.

binEng