ORG, ROI, pem - Specification 03/16/93

[Andreas Arff]

> R e m o t e   O b j e c t   I n v o c a t i o n
>
> Specification Release 0.00 (03/16/93)
>
Hello dear Elger (elg = moose in norwegian)

I have been thinking about Peters draft a lot lately, and also about "my"
device idea. Actually they are relatives, as brothers and sisters. Close as
man and wife. So I have thought, if we get an effective ROI we only have to
do two things to get them work as I suggest, give them a callback function
and a que pointer, and there it is - a fully functional IO device interface.

This can give very interresting features when it comes to networking, you
could actually read another harddisk on the net, use it as your own.
You could let ten users write in the same document at the time by connecting
your keyboard-device to their keyboards, and their screen-device to yours.
Of course, if this is possible there are no longer any security at all, a
total resource anarchism, and it could also be turn into a totalistic system
ala' George Orwells "1984"! But - this can be overcome.

Now about the use of the words invokee/invoker vs. client/server, actually
the use of client server suits my purpose _much_ better, because there
are no clear difference between invokee and invoker if you attach yourself
to a ROI with a callback function, or maybe still better servent instead of
server:-).

Please enjoy.
#pragma +Flame

Now I'll give you my suggestion for the "event/callback-function" system I
have suggested, with the use of ROI.

It will have the normal abilities as the ROI have;
 - Ability to change the hardware interface at runtime.
 - A dictionary (?) so you can select the IO device you'd preferr (eg. ms-dos
   file-system/unix/os/2(/vifs?))

ROI "extensions" to IO ROIs
 - Have a callback function that is called whenever there is IO the user is
   connected to. See example/idea 1.
 - Have a pointer to the task-ques last element pointer (very unabstract
   written). See example/idea 2.
 - The ability to either just post a message or to stop the multitasking if
   it must do so (ie. if a task does something critical which has to be delt
   with imidiatly!)
 - Whatever you can think of...


Now my two examples, in C and C++.
Example 1)

client.c
  #include "keyboarddev.h"

  .
  .
  .
  /* myKeybFunc = my keyboard function
     szUniqueName = a string that is unique to this application, suppsedly
                    given as argv[1] to prevent that others have the same
                    name
     dwInputIDxxx = if you have several input fields you might want to
                    have different (strings for them) input functions to them
     ptrMyQue = so the server knows where to put the callbackfunction and its
                parameters.
     last define = How much work should the device do for you, do you want
                   the scan-code or the character.
  */
  AttachToKeyboard (myKeybFunc, szMyUniqueName, dwInputIDxxx, ptrMyQue,
                    KEYB_ALL_INPUT);
  .
  .
  .
  /* Later you might use a ready-defined function. */
  ch = getchar ():

keyb-server.c++
class Keyboard : private BaseIODeviceClass
  {
    public:
      getchar ()
        { // Yes - I ident the parantheses too, and I don't use K&R style!:-)
        AttachToKeyboard (...); // Look in client.c
        }
      AttachToKeyboard (?);
      AttachToKeyBoard (?,?);
      AttachToKeyboard (?,?,?);

      KeyBoard (?);
      KeyBoard (?,?);
  }

Keyboard::AttachToKeyboard   ((void *) itsFunc, long ID, void *ptrQue);
  {
  InsertFunctionInTaskXsFunctionListWithItsInputID (itsFunc, ID);
  InsertPointerToLastElementInQuePtr (ptrQue);
  }

Keyboard::AnyKeyboardEvent (struct stdParameters wackiwacki)
  {
  long i,
       j;

  j = Semaphore->On(TaskXsQue);
  /* Or better DontMultiTaskYet (); */

  i = FindOutWhichInputFieldHasFocus ();
  i = GetFunctionNoDependingOnWhatHasFocus (i);
  PutFunctionInTasksEventQue (TasksFunctionXAppliedQuePtr[i], wackiwacki);

  Semaphore->Off(j);
  /* still better OkToMultiTask ();
     this prevents another item to wait for the que to become unlocked and
     to spend all its time doing nothing!
  */
  }


Now to example two.

    +---------+
    | Obj X   |           +------->[PtrToLastElementInTaskXsQue]---+
    |_________|           |                                        |
    |[QuePtrY]| ----------+                                        |
    +---------+                                                    |
                                   +-------------------------------+
                                   |   +----------------+Que
                                   +-->|[LastQueEntrie] |
                                       |[...]           |
                      +--------------->|[FirstQueEntrie]|
                      |                +----------------+
                      +-<KickFunctionInFirstQueEntrie (...);

Now how the que should/could be served.
 I suggest a (circular?) list/que.
 If you need to get your message through before any other you can just
 insert an item before the first entry in the que and update the pointer
 to the first item.
 Then you kick(launch is probably a better word but kick sounds much better
 :-)each item in the list as you traverse it.
 Whenever you insert an item last in the list you update a pointer to the
 last item. The address of this pointer is made "public" to all devices so
 they can update it.


Before I turn of flame; I don't say that ROI and this is the same thing, only
that I could give us a lot less work if it were, so don't take my scalp if
you don't like it.

#pragma -Flame

Ok guys, have a nice (Satur) day..., while I'll have to do some work:-)


Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--