Clipboards + Meaning

[David E. Manifold]

On 10 Dec 1997, Eric W. Biederman wrote:

> >>>>> "Jano" == Jano John Akim Franke <j.j.a.franke@t-online.de> writes:
>
> >> Or more simply you make a system wide object system available.  Make
> >> lots of standard and semistandard object types.  Then you can
> >> communicate more clearly, by passing both the message/object, and how
> >> to understand the message (it's type).
> 
> Jano> Do you require passing the "type". If so, this would lead to eventually
> Jano> incompatible parallel development of APIs with all its disadvantages,
> Jano> wouldn't it?
> 
> Passing type information yes.
> 
> parrallel development of API's is healthy.  

Yes!  We need competition at all levels of the OS: OS core, standard
libraries, APIs, utility programs, game libraries, network protocols, file
systems... The more different ways of doing one thing the better!  Each
user will be able to combine multiple different ways of doing something to
get what they want.

> C++ unfortunantely doesn't work well with this.

Tunes will work well with parallel development, since objects are uniform,
modular, reflective, and generic.
 
> Jano> I would prefer a more fuzzy thus open storage. So instead of passing an
> Jano> explicit "type" to point to the "API" the latter (information) should
> Jano> find/link to the message/object (information). So you can substitute or add
> Jano> an "API" without restructuring the passing object to pass another "type".
> 
> This is not a operating systems issue but an issue in the design of
> your type system.
> 
> In general an object reference has a data location, and a pointer to
> the a table of functions to manipulate that data.  The important point
> is that the table of functions to manipulate the data is not needed to
> be derived from the data (as in C++).  Therefore all you need to do is
> change the functions, to what is expected.  The negotiation however
> can get tricky.
> 
> Further this global object system must essentially be implemented with
> either shared libraries,  or out of process procedure calls, to a
> server that effectively acts as would a shared library but is more
> reliabe/secure because it is in a different process (on who knows
> which machine).
> 
> Look at CORBA & ActiveX for attempts to implements this system wide.

Tunes should eliminate any difficulties involved in designing such type
systems...

* fine grain parallelism: light process model
* dynamic compilation: no static monolithic executables
* uniform modularity: all objects are basically shared libraries
* Security by proof: no isolation boxes

David E. Manifold
tril@bespin.ml.org