From: mmcg@cs.monash.edu.au (Mike  Mc Gaughey)
Subject: Re: Distributed lpmud
Organization: Computer Science, Monash University, Australia
Date: Tue, 15 Dec 1992 20:30:34 GMT

amylaar@mcshh.Hanse.DE (Joern Rennecke) writes:
>oreillym@tartarus.uwa.edu.au (Michael O'Reilly) writes:
>>Michael Moore (mdm@hadrosaur.cis.ohio-state.edu) wrote:

>>getting to be on it's last legs. The lack of strong typeing , and the

>And i don't know what for you want strict typing, but you can turn it on
>as an option.

His idea of strong typing is clearly stronger than yours :)

Each object template defines a distinct type, and, except for function
overloading, there are no disjoint union types.  Thus, a generic
"object" handle doesn't exist; you can only deal with object types
you know about.  I'm sure he has extensions for this to manage
inheritance (which is how generic "room" things would have to
be handled - if you don't want to have to load every room on the
mud on startup, that is).

>>This also simplifies security. You have an object

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

The comments on security are in the same vein - to make a "secure"
object, simply give it a private (non-export) type; noone else will
be able to get a handle on it (or know what to do with it).

Although these ideas seem ludicrous at first sight, operationally they
are very close to LPmud 3.0 - where you have to *know* that an object
inherits <blah> if you want it to respond sensibly to operations on
<blah>.  The difference is that this makes it explicit.

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

Oof.  No effect - you either have to broadcast each time you
create an object, or the other mud has to query you anyway.

>>that is a file-system handle. Only objects that have that handle can
>>access that file-system. Instant security.

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

Nope.  In our driver, if a path "a/b/c/d" is referenced, and the object
isn't in the hash table, and some object named by a prefix exists
(e.g.  "a/b"), a hook in that object is called, asking for the object
named "a/b/c/d" (this came out of a need to be able to completely
divorce object names from filenames).  Thus, wizards can implement
directories (and virtual rooms, and all those other things) as LPC
objects, and can implement their own security code in functions like
"ls".  Under Michael's strong typing scheme, one could conceivably
enforce read-only security by only exporting an object consisting of
"read" functions.

In any case, I'm pretty sure that doing file security using this type
of type hiding mechanism would be an abuse of the Australian Sanitation
Standard.  Ugh.

Mike.

ps: Michael: what happens if two objects need handles on each other -
e.g. room and std object?  How is the first compiled without
knowing the type of the other?  Or is the typechecking enforced
purely at runtime?
--
Mike McGaughey			AARNET:	mmcg@bruce.cs.monash.edu.au

"Head stompin', ass kickin', finger licking nastiness"
Newsgroups: rec.games.mud.lp