On method numbers [djg8]

David Garfield uunet.uu.net!davgar!david
Wed, 24 Mar 1993 23:48:37 EST


"> " is Andreas Arff On 24 Mar 93 09:30:11 +0100
"> > " is David
"> > > " is Andreas Arff On 23 Mar 93 10:36:45 +0100
"> > > > " is Michael WINIKOFF writing "Kernel -- The Second Attempt"

[discussions of objects dropped]
> > > >         Issues:
> > > >             What is the type of the name?
> > > >             An integer is the obvious.
> > > >             When would the allocation of these be done?
> > > The integers? At compile time. When you create an object, the object will
> > > already contain numbers for its methods.
> > > If the OID is distributed at runtime there wont be any OID.method crashes.
> >
> > I think I would rather see a set of numbers predefined for all objects
> > (though objects need not respond to them), and other numbers be
> > allocated at run-time, on a system-wide basis.  I will admit that this
> > will require remapping some numbers in a networking environment, but I
> > think we can live with this.  The name to number translation can also
> > be reversible, which can simplify writing debuggers and similar
> > functions.
>
> How are these #predefine NUMBERS going to be distributed. By a central bureua?
> Each task has its own number, within the task there are objects, within the
> objects there are methods.
> This gives use: TASKNUMBER, OBJECTNUMBER, METHODNUMBER.

OIDs have already been described as unique system-wide.  I am arguing
that method numbers should also be SYSTEM-WIDE.  This gives us:
OBJECTNUMBER, METHODNUMBER.

This gives us two categories of method numbers.

The first is a set of predefined numbers.  These numbers are defined
by the gods of moose (us), once set will never (after first public
release) be changed, and will be usable by all objects.  Amongst these
predefined numbers will be things like
        Inquire_Subobjects(?),
        write(void *buffer, int length)
        read(void *buffer, int length)
        DisplayOn(?)
Simply, anything very common or basic could wind up here.  In fact,
EVERY (predefined) method of the root class would be a predefined
method number, as well as most methods from common abstract classes
(like a video object).

The second category of method numbers is numbers allocated while the
system is running.  My thought is that, when a program is loaded, the
list of methods in the header is passed to a kernel routine that
manages name to number translation.  Any name that isn't found is
added as a new number.  The numbers thus obtained could then be used
to modify the loaded image so that, once the program is running, it
does know it wasn't a constant.  If a program needs to, for one reason
or another, it could invoke kernel routines for name to number or
number to name.

The truth of the matter is that the first category could be eliminated
completely, but, I think that by having it and by putting the right
methods into it, we can eliminate at least 95% of the translations.
This would be a good thing if just for the sake of efficiency.


> In a networking system we will also have MACHINENUMBER.
> With these four numbers you can identify everything down to a simple
> method.
> Machine number will be fixed (for long periods), the task number will be its
> launching number and each object will get a sub-number. The method number
> and the object number could now be distributed at compile-time. I could
> address an object in your machine with this scheme via internet.

In a network forwarder, I would prefer that the forwarder handle
translation of OIDs and Method numbers from one machine to the other.
In this case, the local alias of the object can include the remote
machine identification and object identification.

You can't address an object on my machine via internet.  I'm not on
internet, just usenet.  It will interesting to see you address objects
on my machine via MAIL.  :-)  Actually, I want to try it!

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