Kernel 0.1, Win [djg6]

[David Garfield]

On Tue, 23 Mar 93 13:48:25 EST, "Michael David WINIKOFF" 
   <winikoff@mulga.cs.mu.OZ.AU> wrote:
> In-Reply-To:  <9303222359.aa24193@thorin.cis.udel.edu>; 
>    from "Gary D. Duzan" at Mar 22, 93 6:59 pm
> > 
> > In Message <9303212331.9646@mulga.cs.mu.OZ.AU> ,
> >    Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au> wrote:
> > 
> > =>>    Types are a sticky issue. They are basically language-specific, and
> > =>> we are building a system that needs to work across languages. I don't
> > =>> think we can expect to teach the kernel about every data type that
> > =>> comes along, so I think that any type checking would have to be done
> > =>> at one or both ends of the communication rather than in the kernel.
> > =>
> > =>Yes.
> > =>Do you have any suggestions on the mechanism for doing this?
> > 
> >    Well, the most efficient would be to ignore types altogether and
> > assume that both ends know what they are doing. We could also define
> > some standard types (8/16/32/64-bit signed/unsigned integer, floating
> > point, fixed length string, variable length string, etc.) and require
> > that all IPC use these types. We could also provide libraries for
> > each language to convert language types into system types. Expanding
> > the libraries would allow for more system types. I don't know if
> > this is a good idea, but it is an idea.
> 
> It's the simplest for us but it causes problems with robustness.

One possible way to have a reasonable change of getting the parameters 
right is to encode the parameter types in the method name, like C++ 
name mangling.

[stuff about persistence deleted]
> > system (logs & checkpoints) to deal with crashes, but that would be
> > quite a chore.
> > 
> > =>> [ stuff about communication semantics ]
> > =>>
> > =>I think providing all three  at the user level is what we should do.
> > =>WHich get done at the kernel and which get done by libraries I'll leave
> > =>o experts in the area (like yourself) to decide.
> > 
> >    However, the system will be more coherent if we encourage a
> > particular communication mechanism.
> 
> Yes -- which? :-)

The point IMHO is to allow the object class to support single threads 
with queuing or multiple threads, and to allow the invoker to use 
synchronous or asynchronous invokations, and to encourage applications 
and classes to use the techniques that are appropriate for what is 
being done.  By preference, class should support multiple threads and 
applications should to synchronous calls, but for some uses, other 
techniques should be used.

> >                                         Gary Duzan
> >                                         Time  Lord
> >                                     Third Regeneration
> >                          Humble Practitioner of the Computer Arts
> --------------------------------------------------------------------------------
> 
> Michael Winikoff
> winikoff@cs.mu.oz.au
> Computer science honours. University of Melbourne, Australia.

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com