[536] in Coldmud discussion meeting

root meeting help first first in chain previous in chain previous next next in chain last in chain last

Re: To-Do list..

daemon@ATHENA.MIT.EDU (Sat Nov 5 18:35:26 1994 )

From: brandon@avon.declab.usu.edu
To: coldstuff@MIT.EDU
Date: Sat, 05 Nov 94 14:16:42 -0700

< This basically allows an object to listen to more than one port, 

My main question is why do you want to?  You would be adding another layer
of complexity no obvious gain, where the gain in keeping it simple is it
IS simple.  So you can only have 1 connection / object.  That isn't a big
deal because objects are cheap.

< The only problem with this being you'd have a screw case that'd require
< a significantly different command line to start even just the server
< part.

Would anybody ever actually want to add such a functionality to the server?

< Like I said, it would make maintenance very awkward, it would destroy the
< model of the DB as a more-or-less self-contained system, and it could
< easily be implemented in-DB with protection for compile() and the like.
< Private/local is a good idea.  This is not.

_how_ would it destroy the model of the DB?  If you look at it as something
created and used online I can somewhat see this view, but a db is not only
created online.  There is a lot more to a db than just online editing, that
is why Greg had enough foresight to add in additional functionality to
the db format (such as eval and the ability to comment virtually anywhere
you want).  By 'locking' a method what you are saying is 'upon moving
into an online state this method should never be changed until the server
moves out of said online state'.  What I see as a security mechanism you
see as some sort of anti-christ to the underlying theory of ColdMUD. Please
EXPLAIN why this is.

-Brandon (Lynx)-