meta-protocols (was: a no-kernel system)

[Francois-Rene Rideau]

[All these message series are answers to Mike]

> In order for my object to replace anothers (upgrading);
>   1.  I must know what services the old object provides.  How does my
>       new object find that out?
   This is a matter of meta-protocol. To be linked, an object had to
follow some meta-protocol that described how it could be linked (that
is, the calling convention/Low-level specification). Why not allow also
high-level specification ? Our low-level machine being abstract, and
our not wanting it to be an absolute abstraction (like MS-DOS' 80x86
processor), why not allow *any* abstraction ?
   Thus, among these abstraction, providers will be encouraged to
include just *anything* that may constitute a specification, so that
users may be sure that the object is exactly what they need ?
For example, you may just say that such function takes a list, and
returns a list; but why not also tell that the result is the sorted
input list; and why not also add efficiency considerations (e.g.
"this function is quicker for tiny lists"; "this one is quicker for
large lists"; "this one requires an efficient gc"; "this one works
on-place") ? Let's just *allow* and *encourage* it.
   After all, type-checking is just some kind of crash-proofing. If
the program is well typed, it means you cannot crash the type system
and garbage collector. For a no-type system, it does not mean anything;
for a strong type system, it means that no pointer may be faked. For a
full-fledge logical specification system, it may mean that the program
does exactly what it pretends to do.


>   2.  In a persistent system, you don't restart the computer when you
> 	upgrade, you must inherit the state of the prior object.  How
>       does this happen?  Does the old object provide the info?  Or
>       does the OS have some way of capturing it?  How do you
>       identify and use the old objects data structures?
   Hey, just the same way as it does migrate ! Migrating from a software
environment to another is no more difficult than migrating from a hardware
environment to another. It is just more generic, more powerful, more
*useful* !
   How did you expect to migrate objects from one computer to another ?
You had to abstract the hardware. But why abstract just the hardware ?
After all, different hardware provide different services. Did you expect
to provide only a greatest-common-denominator ? Or a least-common-multiple ?
Both approaches are dead-born; for the GCD is just *nothing* (or just the
ALU); while the LCM is just anything, evolves very fast, and nobody can do
it. In any way, you must provide software modules, and among those, different
and evolving device drivers to allow access to different and constantly
evolving hardware. And providing modules is just abstracting anything,
because when you migrate, you need different modules to provide the same
interface to different hardware.
   That's how I conceive things. Please tell me how else it could be done
without having some micro-kernelish nullware or some unixish hugeware.

   As for the exact mechanism, that's a matter of reversible functions:
any hardware dependant code/data specialization, that may be invalidated
by migration or upgrade, must be such that the source *and* current machine
state may be retrieved, so that another specialization may be done. The
easiest way to recover the sources is just to keep it (no need to have
it in physical memory, though; it only needs be accessible from disk,
network, or decompiling function); as for recovering the machine state, it
means any optimization done is reversible, and a reverse function is kept.

   To conclude, I agree those indeed are important questions. I hope the
(generic) answer pleases everybody, so we can be more specific later
without having to rediscuss the general solution. So don't you say Mike
that I'm too generic; we can't agree on specifics if we didn't agree on
generics before. I'll can indeed be specific only later later, so we
can only hope to agree quickly, so we can be specific faster.