[DGD] Melville under the Kernel Lib

[Stephen Schmidt]

On Fri, 6 Feb 2004, Felix A. Croes wrote:
> If you want to re-do Melville on top of the kernel library, you have to
> move files around.  That is a given.

Yep. I don't think you'd actually have to move very much. Mostly
what you'd have to do is remove Melville's current security based
on file paths, and build in a security system that conforms to
the kernel's methods, which are far more secure, but not as
easy to work with. (Melville deliberately gives up some security
for ease of use. I can speak at length on that topic but won't :)
My experience is that most mudlib security problems occur not
because the system is insecure, but because an under-educated
admin has messed up somehow. So I think a weaker security
system which a relative newbie can work correctly is actually
more secure than a complex and safe system but one which the
newbie adminstrator will not configure correctly. That's a
debatable point, of course. It may be less true now than it
was in 1994.)

> Here is what the kernel library does, and what a modern mudlib should do:
> [snip]
>  - A framework for persistence.

I'm not sure I agree. Surely a mudlib can be useful and "modern"
even without supporting persistence? Not all applications require
persistence. (I do concur with Noah that if you use a mudlib that
does not support persistence, you are sacrificing a big feature
of DGD. But DGD has other features besides persistence which can
sell it to someone who doesn't need/want persistence.)

>     - There have to be some kind of thread-local variables which are not
>       held in any object, to handle things such as this_player().

How does one have a variable which is not held in some object?
Even if it be the driver object?

Steve


_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd