INT: Worlds and Generic Services

[The MOOSE project]

[Just BTW; anyone has a HTML version of the GNU GPL v2,
so I put a copyright on the pages ?
And what about
``copyright (c) 1995 Francois-Rene "Fare" Rideau and
		     the members of the TUNES project'' ?]

> -User interaction takes place through "worlds"
Interaction in general; not only "user".

>   -Instead of a login shell, user "logs in" to a world.
Yes. "Opens a view".


>   -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.
   Well, a non-limitative list like "among the interaction media are
text, ....", etc, would be better, I think.


>   -Each world has some subset of the universe of objects inside it
   I'd rather say that worlds are a *context* in the universe of objects;
that they are somehow universes themselves in that meta-universe.


>     -Objects may be added to a world by a "realize" or some other command,
>      then may be later removed/unrealized.
   I think that is what we called migration, according to the terminology
of the Sony CSL.


>     -"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)
   I only half-agree with it: for an object to be "the same", it must
conserve some of its semantics, which must thus be independent of the world
it is being viewed from. Now, each world can *enrich* the semantics of an
object. But multiple worlds mustn't be able to enrich it in unconsistent
ways...


>   -Worlds can enclose other worlds
   Sure !

>     -a world can even enclose a copy of itself
   That's recursivity !
It's fine, but must follow some consistency conditions
(i.e. so that the recursive definition converges...)


> -Where are objects when not in a world?
   They do not exist anymore.
   But of course there are some lowly active world for storage; that is,
world where objects receive no message, but are ready to be migrated again.
E.g. a disk...


> -Can an object reside in multiple worlds at once?
>   -yes
   Yes, and this is a most important feature of TUNES, that we shall not
withdraw: objects can live in several, different contexts; people can have
various independent point of views on objects.


> -Do worlds encourage abstraction?
   Ahem. What do you mean exactly by "abstraction" ?

> -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...)
   Again, to the system, a "user" is just some context/world.
Objects being shared by users is thus just a very particular case of
objects being in multiple worlds at once. Actually, having the particular
case without the general one (which is what is being done in current design)
is just lame, unefficient, and the proof that existing system
designers understand nothing of what a system is.


> -Communication between worlds
>   -done only with objects, or do we allow sort of sort of "portals/warps" to
>    other worlds?
   "Worlds" being objects, communication between worlds is done by their
meta-objects which "magically" link objects without the objects knowing,
their seeing only legal operations being done in some "magic" order,
from some "magical" input.




> 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.
>[...]
> 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?
   Both are two sides of the same problem: define specifications of
objects, and use these specifications. Combining objects requires a
formal or informal "proof" of the specifications, and finding an
object is just proving an existential specification "there exists an
object such that...".
   We won't give info for "every possible case", which is impossible,
because we want maximal power, and thus have infinitely rich systems
so "every possible case" will not fit any finite memory. Instead,
there will be some human-controlled inference system. Interesting
proofs will be cached in databases; particularly, packages come with
standard proofs and ad-hoc provers so they can be used easily. If no
proof is available, standard programmable tools are provided so the
user can try find a new proof. As TUNES evolves, more or less complex
AI programs will appear and relieve the human from doing those proofs.
Meanwhile, superusers have the "admit it" tool, too, so they need not
be good at logic to have programs run.



> 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?
   Sure, sure. We shall provide the most simple possible installation,
with automated mutual recognition of software packages: software being
uniquely named, and coming with formal and unformal specifications, this
is a very doable task; some AI could later allow the system to run with
less explicit information. Now, if we control the software, we do not
control the hardware, and thus we cannot be sure to install fully
automatically and recognize all the hardware at the same time.
   To conclude, software installation will be automatical and programmable
(i.e. under full user control). Default installation will be secure, but
will propose the user to try less secure hardware modules, and choose the
options for modules in general.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"