From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly)
Newsgroups: rec.games.mud.lp
Subject: Re: Distributed lpmud
Date: 16 Dec 1992 14:16:06 GMT
Organization: The University of Western Australia
NNTP-Posting-Host: tartarus.uwa.edu.au
X-Newsreader: Tin 1.1 PL5

Mike  Mc Gaughey (mmcg@cs.monash.edu.au) wrote:
: 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:
: >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 :)

Very true. Lpmud's idea of typeing is simply checking it where it can,
and it doesn't even do that if it looks too hard.
 
: [ explnation of what is meant by strong typeing. ]
: 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).

Yup. Also the concept of code shareing is seperated from sub-typeing.
(An class A is sub-type of B if it "inherits" it. i.e. implements all
the functionality of A plus maybe some more). An object can say that
it does everything the super-type does without actually needing to use
any code, and vice versa. This simplifies a fair number of things.
'virtual interfaces' seem to come in handy a lot.

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

True. As you point out I am not certain you actually want to base
your entire security on this, but it would certainly reduce the
load the driver has to carry and thus make it more general.
Ideally I would like to remove any knowledge of security from
the driver altogether.

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

No, you mis-understand. As there is no find_object(), the only way you
can tell if the object "xyzzy" exists, is if someone gives you the
handle of it. (This being strongly typed, and non-forgable). This is
totally distint from inheritance of any sort. 
 
: [ A neat scheme for virtual objects + nice wiz security deleted. ]
: [ Hope mike doesn't mind if I pinch that. :) Who should I credit ]
: [ it too?? ]
:
: 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.

Grin. As I haven't actually implemented it yet, I am not sure how
practicle it is. Does anyone have any references on security in an OO
system??
 
: 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?

Hmm. I am rather happy with my compiler, if a little alarmed at the
size. I DON'T compile on the fly. 

I actually tokenize the entire source file, and build a nice parse
tree first. Then I do a semi-breadth first search so that I know all
the class names before I use them, and then I know all the class
interfaces before I need to use them.

Haveing done that, I then compile function by function, filling
(known!) forward references as I do so. This eleminated the need for
prototypes.

There is still a problem in that if two different source files both
reference each other, they both need to be compiled in one fel swoop.
Can't see an easy way of getting around this.


BTW: Any comments on seperating class definitions from the file
system?? In Lpmud, the object name (usually) comes from the source
file. In my system, the class names, and class libraries are othogonal
to the file system. Any comments on the wisdom of this??

Also, I implement security on access to system resources by simply
implements classes as an object, and then passing to the compiler, an
array of the classes or class libraries that it knows about. (The
number of global variables in this driver is tending to about 1. :)

Commments?
: Mike McGaughey			AARNET:	mmcg@bruce.cs.monash.edu.au


Michael O'Reilly.			oreillym@tartarus.uwa.edu.au

Ps. Problems I am still looking at:

Quotas! How to handle these? The high level of security seems to beg for
user level programming. Problem is resource allocation. How to limit it.
Whhat happens when limits are reached. An object gets created, where do
you credit the resource-usage?

Exception handleing? General failure handleing?


Newsgroups: rec.games.mud.lp