From: amylaar@mcshh.Hanse.DE (Joern Rennecke)
Subject: Re: Distributed lpmud
Organization: Point of Presence & MCS Hamburg
Date: Mon, 14 Dec 1992 18:07:18 GMT

oreillym@tartarus.uwa.edu.au (Michael O'Reilly) writes:

>Michael Moore (mdm@hadrosaur.cis.ohio-state.edu) wrote:
>: 	Hey folks!
...
>I am working on a truely OO system. It is persistent, multi-threaded,
>and (will be) distributed. I choose to start from scratch, as LPmud is
>getting to be on it's last legs. The lack of strong typeing , and the

Hmm, i think LPmud has still not reached it's climax.
And i don't know what for you want strict typing, but you can turn it on
as an option.

>horrible compiler are two of the reasons for this decision. The
>compiler you can fix, the typeing you can't.

>The other really big problem with Lpmud, is that 'find_object()' is an
>integrel part of the mud. This pretty much kills you as far as making
>it properly distributed goes. (Can you imagine the network traffic
>involved in doing a find_object() on a non-existant object.)

>The solution to this is to get rid of find_object(), and ONLY allow
>access to objects you know the handle of. This is fine because you
>never need to search to find an object. The handle will tell you
>exactly where it is. 

There is also another solution to it. Have a number of authoritative
find_object() servers distributed accross the net. Immobile objects might
even be resolved analogous to the domain addressing.
The maximum speed of effects propagated between muds should have an upper
limit, analogous to the relativity theory, so that it's sufficient to
know that a mud hasn't created object x 10 seconds ago to say it's not
existent in your inertial system.
Clone names have to represent their origin mud, so you can always ask
the originator first, which is a good bet, if you have not recent enough
information.
To reduce the traffic to the find_object servers, you can also cache the
results of the most recent external object lookups.

>This also simplifies security. You have an object

Uh, where does find_object() come in here ???

>that is a file-system handle. Only objects that have that handle can
>access that file-system. Instant security. Strong typeing allows you
>to have limited access to a file-system. You have class File_system
>inherit File_sys_ro, and then if you cast file_system to file_sys_ro,
>you can give away the handle safe in the knowledge that they can only
>look, but not touch (Safe, as casting in the other direction is an
>error. You can only cast to a super-type, not a sub-type).

Do you want every wizard's object to inherit the file system of this
particular wizard? This prevents clonable, configurable objects.

>This also simplifies garbage collection. You don't need the
>'destruct()' kludge, and can simply deallocate object that don't have
>any references. (As if there are no references, then nothing can ever
>use that object again, as it can't get access to it).

The real problem with garbage collection is that you can have any number
of references to unreferencable objects and data.
Besides, the fact that you have a working reference path to an object
does not ascertain that you really want to keep it.

	Amylaar