INT: Worlds and Generic Services

['Chris Harris' B. Harris]

Hello TUNESers!

Been pondering lately how to set up a UI framework, as well as how TUNES 
will provide generic services, to the extend that Fare describes in his 
CD Database example.  (If you haven't read that, perhaps you should -- I 
wish my computer could do that!  =)  So here I am, to present a few 
thoughts and solicit some feedback (as usual)....


First, about the UI framework: been thinking about how we could create a 
flexible, expandable environment with minimal abstraction, maximum 
coolness.  I haven't come up with anything extremely concrete, but I have 
made the following little sketch.  If it sounds like this is on the right 
track, maybe I could expand this into a "paper".  If not, I'd love to 
hear rash modifications or alternate proposals!  Anyway, here goes...

*****

Sketch
------

-User interaction takes place through "worlds"
  -Instead of a login shell, user "logs in" to a world.
  -Worlds might be interacted with via text, 2D/3D pictures, sound, etc. --
   and different combinations of these (which of these is used depends on
   how the world is set up.
  -Each world has some subset of the universe of objects inside it
    -Objects may be added to a world by a "realize" or some other command, and
     then may be later removed/unrealized.
    -"Realized" objects become part of the world, and abide by the world's
      "physics".  (ie realizing a chunk of text might, in a 2D windowing system
      world, bring up something not too distant from today's word processors)
  -Objects are interfaced to the world through modules/sub-objects, which
   specify the object (visually, etc.) in terms of other objects in the world or
   low-level graphics/audio/etc primitives.
    -Normally, one such module exists for each world an object can interface
     with.
    -But there are exceptions -- world may provide for "generic"
     object support, where users can interact with an object just by setting
     attributes, etc..  (For example, in a world that doesn't support input
     siders (used for volume controls, etc.), a user might still be able to
     set some object's field to a value between 1 and 100 to control the
     slider's value.)
  -Worlds can enclose other worlds
    -a world can even enclose a copy of itself
      -to achieve this, worlds must be careful to access drivers (that can be
       emulated) and not the hardware directly.  Sure, some worlds could
       access the hardware directly, but this is not reccomended, as it makes
       that world impossible to run within another world.
  -(?)Worlds help provide security: only objects in current world can be
   accessed (by the user anyway).
  -(?)Worlds can help provide context/speed: if a world is setup so that no
   objects outside the world can be accessed, the search space (hence time)
   is lowered drastically?  (Is this REALLY what we want?)

Issues
------

-Where are objects when not in a world?

-Can an object reside in multiple worlds at once?
  -yes

-Do worlds encourage abstraction?
  -Support yes, but not encourage.  Abstractions can be created (as sub-worlds,
   perhaps) as needed, but part of the worlds system's advantage is how easy
   it is (?) to NOT provide abstraction.  Say I have a text object that I want
   the user to edit.  I can simply plot this object in the user's world, and
   it'll figure out what to do with itself.  That way, I don't have to support
   it with any of my time/code.  (Not sure how that relates to abstraction, but
   oh well...)

-Multiuser worlds?
  -Sure, why not?  Let as many folks as need log in to a given world, and
   interact with the same stuff!  (Or would this result in pointless control
   fights?  This needs to be refined...)

-Communication between worlds
  -done only with objects, or do we allow sort of sort of "portals/warps" to
   other worlds?

Cool thoughts
-------------

-Text objects created as sub-worlds, with their own "laws" appropriate to text,
 etc..

*****

About generic services: seems to me that due to the lack of sufficiently 
advanced/cheap AI items, requests such as "provide me the best database 
module availible" (going back to the CD Database) are going to have to be 
translated into some sort of structure request, and then the appropriate 
module found simply by pattern matching with similar structures attatched 
to objects.  Something like this:

struct objectRequest {
  ulong object_type; // 5, for example, might be our standard database 
                     // ID #
  char  *attributes; // special needed attributes needed by this database
                     // module to satisfy our needs
object };

Sure, it's ugly, but how else can we do it without some big ol' AI thing 
that hasn't been invented, or is out of our reach if it is?

Harder than this, I think, in Fare's example, is the part where the 
system basically goes to ask the database object how it works, and the 
module replies with the appropriate information.  Pardon my French 
(hehe...), but how the hell are we supposed to communicate that 
appropriate info for every possible case?  Any thoughts on this?


Oh, and I think TUNES should have one standard installation package that 
does more than make, imake and all those others put together.  The amount 
of effort needed to install some UNIX apps is just silly.  I know it 
can't be as simple as Mac/Win, where you just plop the app there and it 
works.  (And binaries won't work anyhow, if we want to support 80 zillion 
platforms someday....  =)  But, assuming we trust the source code, 
couldn't things be more standardized, and hence more easily automated?


Feedback is welcomed/begged, as usual.

-Chris

--------------------------------------------------------------------------
"Be careful lest in casting out your devil you cast out the best thing 
that's in you." --Nietchie %% Me = Chris Harris (chharris@u.washington.edu)
Check out my web page: http://weber.u.washington.edu/chharris/