Contents

Subjects under discussion
      Feeble attempt to distill the various threads into major subcategories.

   Glossary of Terms Bandied About
      List of terms defined or used freely, and an approximate description of
      what they mean, not necessarily correct.

   References
      List of external references used in the discussions of the week.


Subjects under discussion:

   BOSS

      Lowest level of abstract services (HAL) supported by the hardare. Hardware
      adds services to the BOSS which then presents them to the OS. BOSS is
      thus more than a kernal, it is also an Object Request Broker.

      BOSS thus allows for a similar type of dynamic object environment to HAVi
      -- see URL in references.

      Counterpoint was proposed that a more OO approach would be better, where
      the OS consists of 'objects' (for example, a "sound" object) with known
      requirements and attributes that a hardware designer can address. The
      emphasis on this approach is to keep things as simple as possible, only
      introducing complexity when absolutely needed.

      Additionally, in such an object-oriented environment, hardware 'objects'
      could be arranged in class tree structures; a 'family' structure trending
      from more general (e.g. 'sound') towards the more specific (e.g.
      'SOUNDMONGER PRO' audio card). One could talk to the "sound" object in a
      general way (e.g. send a sound file to it) or talk to the
      "sound/SOUNDMONGER" object directly. The advantage of talking to the
      'sound' object is that it will (actually, SHOULD) know that the
      SOUNDMONGER exists and thus will send the data in the correct format to
      the card. On the other hand, the 'sound' object might determine that the
      file being sent was more appropriate for the 'MUSICMONGER' card and send
      it there instead.

      Using this approach, one could possibly store drivers in a hierchial
      directory structure.

      Also see the "Object Sea" and "Registry" subjects

   FireWire

      It is suggested that KOSH should implement this.

   Memory / Object Access

      Use of pointers as references to objects is probably not a good idea in a
      true virtual object sea. Everything should be by reference. Reference
      gives ownership, an extended degree of SW memory protection as well as
      other advantages.

      (This concept currently meets with great resistance from many fronts :-)

      A counter proposal: The primary denizens of the object sea could be only
      "Capital" objects (see Object Sea subject) which encapsulate smaller
      objects such as lists, strings, etc. Pointers within capital objects are
      allowed, pointers from within one capital object to WITHIN another
      capital object are NOT allowed. When there is a legitimate need for one
      capital object to know about another capital object or its contents, it
      uses OS functions to do so safely.

      Speed might be an issue here, so it is possible that Capital objects would
      communicate directly with each other in a limited fashion (to limit the
      possibility of violating the memory space of each object).

      Related is the discussion of the Four Spaces: if a Capital object is
      'trusted' enough, it might have need and means to bypass the memory space
      integrity of another capital object.

      An important question comes up: if KOSH is intended from the beginning to
      be friendly to distributed processing environments, then passing data by
      reference (pointers) is not possible -- the actual data must be passed
      from processor to processor to be within its memory space.  Or, possibly,
      we design for speed (indirect referencing of data possible) at the lowest
      level, and rely on system extensions at a higher level to allow the
      addition of additional processors.

   Object Sea

      This came up as a sub-thread of the BOSS discussion. The term "Object Sea"
      might imply to some that there is chaos rather than order in the
      organization of the various objects that make up the BOSS and OS. However,
      this does not have to be the case.  One such proposal is for a series of
      "chart objects" to make up the lowest level of the OS kernal itself. The
      kernal would thus be built up of a series of objects, with a primal root
      object class to get things started, and all the various functions of the
      kernal (e.g. creation and removal of tasks, etc) being sub-classes of it.

      An example of how powerful this could be is given. Consider if a new
      task would normally be created using the system/kernal/task object.
      However, suppose the developer needs more debugging information. If a
      special debug subclass of the task class is provided, then the new class
      could be created using a system/kernal/task/debugtask object.

      Do we want to use the hierchial file structure for storing objects, or a
      less rigidly organized semantic set? The advantage of the latter is that
      it doesn't FORCE the hierchial view on the end user, but DOES allow it.

      It's more than just a way of viewing the system, though. In a semantic set
      structure, all objects in the sea offer thier services to all others,
      similar to the Amiga library system in many ways. It is possible with the
      hierchial structure that objects will become too overburdened handling the
      traffic up and down the 'chain'.

      Some caution is probably warranted, though. If every string, list, or
      integer in use is in fact an object in the object sea, and thus
      known to all other objects, things will very likely crawl. The term
      "Capital object" came up to describe the primary denizens of the sea; it
      is assumed that the minor objects mentioned above would be 'passengers'
      of these Capital Objects (keeping with the nautical terminology).

      Also, a hierchial structure imposes dependencies; the child class depends
      on the parent class to pass it data of a certain type. Change the parent
      class in such a way as to change that data, and the child class must
      likewise be revised.

   Registry

      Or, whether to use one or not.  It is possible in the object sea for
      parent objects to 'know' what kinds of data are appropriate for them or
      thier children objects, thus eliminating the need for a registry. Thus,
      the 'sound' object, upon receiving an audio stream, sends it to the
      SOUNDMONGER object. OTOH, upon receiving a MIDI score, it might determine
      that none of its children can handle it and thus not pass it on.

   Space, the final frontier

      At least four realms of 'protection' are needed for the object sea to work
      properly; System, Object, Shared, and Local.

      System space is where the low level stuff works: kernal tasks, driver
      objects, system objects, etc. System space can 'see' all other spaces, and
      no others can access system space directly. Errors in system space
      probably result in a system crash.

      Object space is for trusted objects not as critical as system objects.
      Objects in this space can see most of the OS, but cannot access the
      system space. Kernal objects in system space can allow themselves to be
      seen by object space (e.g. for messages to be passed).

      Global space is intended for threads to communicate quickly with each
      other. Object space objects can permit themselves to be seen in global
      space for message passing. Plug-in object classes would live in this
      space, as well as certain un-trusted that need to be regionally shared.

      Local space is where application objects live, similar to what is seen in
      Unix and similar OSs.


Glossary of Terms Bandied About

   BOSS
      Basic Operating System Services

   Capital Object
      Primary denizens of the Object Sea. Smaller, 'local' objects that do not
      need to be known to all other objects in the sea are encapsulated within
      the memory space of the capital objects.

   Class
      A 'template' from which objects are created. It defines a collection of
      data and code, or rather how it is organized and how it behaves. An object
      is created using this template, but the data structures are "filled" at
      time of creation. One class can thus be the progenitor of many identical
      objects.

   HAL
      Hardware Abstraction Layer.  BOSS is the proposed HAL for KOSH.

   MUSICMONGER
      See SOUNDMONGER

   Object
      An instance of a Class. The Class defines the structure and behavior of
      objects created from it. The object itself fills out the structures with
      actual data and performs tasks as needed.

   Object "Sea"
      A collection of object and class descriptions.

      More or less, a class tree for a collection of objects, such as those in
      the proposed object-oriented BOSS. Amiga's MUI class hierchy is an
      existing example of one sort of "sea" of objects.

   OO
      Object-Oriented

   ORB
      Object Request Broker

   Pointers
      Used in this context, a memory pointer is a variable that points to the
      location in memory of some data. This is also known as indirect
      addressing.

   Registry
      A term used to describe a database of information that indicates a number
      of things to the OS. Most common use is to 'register' programs to the OS
      so that it is aware that the programs exist, and what sort of data they
      can handle. Windows95 uses a registry for such things; the Amiga does not.

   SOUNDMONGER
      Super-secret audio card made exclusively for KOSH by BLAZEMONGER, INC.


References

   HAVi (Download the acrobat spec. While 200 pages in size, the first 40 are
   the key.)

   Object-oriented kernal: here and here.

   Programming Model

   XML