INT: Worlds and Generic Services

[Jecel Mattos de Assumpcao Jr.]

"'Chris Harris' B. Harris" <chharris@u.washington.edu> wrote:
> Sketch
> ------
> 
> -User interaction takes place through "worlds"
>   -Instead of a login shell, user "logs in" to a world.

Good start.

>   -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.

And the user should be able to choose which interaction method is best -
3D worlds are neat but are not very good to a blind person. Of course,
some worlds might not make sense with some interaction methods - who
wants a text based DOOM?

>   -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.

A "fetch" function might be the best way to introduce objects into a world.

>     -"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.

Ok, sort of like the "window manager" in X.

>     -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.)

Yes - you might need to "move" from just using the objects to programming
them, for example. Multiple levels of abstraction is a powerful idea. Self 4.0
is comming out very soon - I wish there was some way of you seeing what
they have done there!

>   -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.

You lost me here - what does "enclose" mean and what does it have to
do with drivers and such low level stuff?

>   -(?)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?)

This isn't such a good idea - the objects in the world must be just the
tip of the iceberg - you should also be able to access objects that are
referred to by these objects and so on. I would make the security issue
orthogonal to the worlds idea, or multiuser worlds ( see below ) won't
make sense.

> Issues
> ------
> 
> -Where are objects when not in a world?

Where are the files that are not in the current directory? As long
as you admit a number of worlds, you can always imagine that the
objects are in one of them ( not the current one ). You might not
be able to "navigate" to where the objects are, but you could
"fetch" them to where you are.

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

I also prefer to answer yes, but the Self folks have powerful arguments
against that: it makes objects much less concrete. They believe an object
must have a unique on-screen presence. On the other hand, any object can
be "seen" in multiple places in the object graph that is part of the
implementation, and I think this idea must be reflected in the UI. It
could be something like "aliases" in MacOS or "shadows" in OS/2 ( see
the confusion they can cause to understand what the Self people are
talking about ... ).

> -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...)

Er.. I think we want concreteness, not abstraction. Abstraction is a bad
thing in a UI. The great thing about Unix was how it abstracted disks files,
serial IO, etc into a single idea - but we already get enough of that with
objects and polymorphism without having to add layers to the UI.

> -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...)

Self 4.0 already allows many users to share a window - it is very neat!
There is a great potential here ( why do you think IBM spent 3.3 billion
dollars on Lotus - to get a little of thie functionality with Notes ).

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

There are two issues - communication between worlds and the user
navigating between the worlds. I think the first can be totally invisible
and the second done with "portals".

> *****
> 
> 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?

Structured Query Language ( SQL ) can already do better than that. I
think part of the answer might be Fare's annotations - just sweep
through the objects looking at what they tell you about themselves.

> 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?

This is where reflection comes in - the ability of the system to
"look inside itself" and work with that. This is already present
in Smalltalk, for example: I can ask for the "implementors of #search:"
and get a browser with all of the classes that implement this method.
We are talking about 70s technology here.

> 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?

Binaries *will* work if they are virtual binaries. No need to
install objects - just a method of communicating them ( via internet,
floppies, CD-ROM, etc.. ) from one system to another. It is exactly
the same thing as copying an object from one world to another within
a single system.

-- Jecel