[540] 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 (Sun Nov 6 01:13:31 1994 )

Date: Sun, 6 Nov 1994 01:08:25 -0500 (EST)
From: James C Deikun <jcdst10+@pitt.edu>
To: brandon@avon.declab.usu.edu
Cc: coldstuff@MIT.EDU
In-Reply-To: <9411052116.AA01172@avon.declab.usu.edu>



On Sat, 5 Nov 1994 brandon@avon.declab.usu.edu wrote:

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

Multiple ports per object would not imply multiple connections per object.
It would allow using one object to listen to 50 modem ports, 1 TCP port,
and one port for DECnet access, or for just one TCP port, without
rewriting it at all and never keeping more than one usused connection
object waiting for a call at a time.  Objects are cheap, yes, but why
not save them when it isn't a lot of trouble?

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

Me.

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

I'm not sure how a DB could 'move' into an online state.  'Be put',
maybe.  The important distinction is that when online the DB is
acting as an agent, and when offline it's a static document.  I'm
not sure if this is the real underlying theory of ColdMUD, but the
philosophy I extrapolated from the features that were in ColdMUD,
a philosophy I liked, was that it should be possible to do as much
as reasonable within the running DB, without shutting down the DB
or hacking the server.  I thought of an easier-to-edit DB textdump
as more a failsafe mechanism than a piece of philosophy, since the
more things you can do within the DB the more things you can do to
make it impossible to do anything at all, and by editing the DB
you can rescind these changes in an emergency without retreating
to an old checkpoint and losing all concurrent changes.  It's of
course perfectly possible Greg had other things in mind; I'm no
psychic.  This is just the way I've seen things since a couple of
weeks after I first laid eyes on ColdMUD.

--
James Deikun (James@JHM, James & Splat@BlueMOOn)