INT: Worlds and Generic Services
Mon, 19 Jun 1995 20:00:48 +0200
> -Where are objects when not in a world?
Objects should always be in a world (a context), even if it's the
hardware (it's a hard world ;-).
> -Multiuser worlds ... would this result in pointless control fights?
We can use the physical properties to break any ties - if two users want to
manipulate an object, some force might give feedback to the users
indicating to them that they are not the only one trying to use an object.
Don't take me too literal here - no need for force-feedback input devices
(they do exist), just any kind of feedback will do.
> -Text objects created as sub-worlds, with their own "laws" appropriate to text,
Of course - that's the multiple syntax/ a parser is an object thing.
Just about ANY object may be viewed as providing a context to its members
(methods) and childs, which is reminiscent of the worlds you talk about.
> ... standard installation package ... I know it
> can't be as simple as ... just plop the app there and it works.
> couldn't things be more standardized, and hence more easily automated?
It can't be as simple? It will be! Well, maybe it doesn't work right
away, but it will try to figure out why and fix the problem on its own.
For example, when the Hot Java browser tries to make an applet in some
document work and a class is misssing from the browser's library, it asks
the server that supplied the document to provide the class. Likewise, when
you fetch some program from somewhere, the program must rember where it
came from (reflectivity again) and be able to "ask mom" for help (some
module) when something is missing.
> -Communication between worlds
> -done only with objects, or do we allow sort of sort of "portals/warps" to
> other worlds?
As I wrote in my thoughts on UIs: "Use windows that fill the whole screen
(parent-window) for rooms. Select them by icon or by shuffling them up or
In other words: a portal (maybe an icon) is nothing else than the
representation of another world ("room") in the current one. Entering it
would be equivalent to first looking in it (opening it/ looking inside it/
changing its representation from icon to window) and then making it the
"default view" by zooming it to full-screen size.
I was a little disappointed about the amount of feedback (none) to that
little article of mine, you could at least have said "boahring
... *snooze*" or "who cares?". For those who care, the URL is:
Still, as I mentioned months before, the distiction between the
Interfaces project and the rest of the Tunes project is unclear to me. I
propose we define the domain of the Interfaces project as:
"The issues that pertain to the (virtually) perceived ("physical")
properties of the objects that the user perceives when dealing with the
Enough on this for now...