[524] in Coldmud discussion meeting

Re: To-Do list..

daemon@ATHENA.MIT.EDU (Sat Nov 5 00:59:11 1994 )

From: Alex Stewart <riche@crl.com>
To: jcdst10+@pitt.edu (James C Deikun)
Date: Fri, 4 Nov 1994 21:57:59 -0800 (PST)
Cc: coldstuff@MIT.EDU
In-Reply-To: <Pine.3.89.9411042336.B2071-0100000@unixs1.cis.pitt.edu> from "James C Deikun" at Nov 5, 94 00:17:48 am

> nothing thing.  To me this is the major problem of the ColdMUD
> error handling system, which got fleshed out for me in a
> discussion of similar issues a while back in moo-cows.  It's based
> on LISP catch/throw, which was never really meant for error
> handling as such.  Without resumes, it's way too static, and it
> doesn't really support good stack unwinding right now either.
> These are more basic issues you need to be working on.

Yeah, yeah, I know.. (I read that discussion too) If you want to rewrite
ColdMUD's error handling system feel free.  In the mean time, however, having
_some_ way to control atomicity is better than having none at all, and this
construct would be useful at the very least for avoiding the entirely awful
situation in MOO where for a whole bunch of utility object verbs you've got
:foo() and :foo_suspended() and :bar() and :bar_suspended() and on and on.

> What does this actually involve?  (Besides a really long awkward method
> named $sys.callback of course :)

Not much (it involves an extra builtin, a counter in the server, and a minor
addition to the main processing loop).  Why?

> >   del_name('dbref)          => del_dbref('dbref, #object)
> 
> Does this mean there can be more than one object to a dbref?  If
> it is, I can't see how this would cause anything but confusion.
> If not, why the extra argument?

No, it doesn't, and I don't really know how that extra argument got in there (I
guess I was busy adjusting everything to be consistent and missed the fact that
the second arg isn't needed there)..

>     bind()                    => listen(port, object)
>     unbind()                  => unlisten_port(port)
>                                  unlisten_object(port)
>                                  unlisten(port, object)
>                                  listeners(port)
>                                  listened_ports(object)

Ick.. listen? (I dunno, just an aesthetic thing, but I never liked that name)
Why so many ways to unbind and check up on things?  I don't see any need for
more than unlisten_port(port) and possibly listeners, tho that's a frill,
really (that info can be kept in-DB too).

> Port isn't necessarily a TCP port; just something the server can
> sensibly listen to.  Could be an identifier for a modem, among
> other things.  The other parameters would be likewise genericised.

Well, come up with a good overall scheme for keeping everything properly
generic and I'll look into it.. as it is, I'm having a hard enough time
figuring out a decent way to make pipes and net connections work the same way,
and I'm thinking it might be best to not bother and let the DB construct
generic interfaces (which can easily be done in-DB anyway) instead.  More
flexible that way too.

> >   conn_object.failed()      => .connection_failed('refused/'timedout, "addr",
> >                                                   port, socket)
> 
> Are you sure this shouldn't be an error rather than a callback?  After
> all, this never happens anyplace an error would not be sensible.  I
> could see a case for this back when the server couldn't queue tasks,
> but not now.

Where would the error be thrown?  Are you suggesting that the open_connection()
call should wait for the connection to be established or fail before continuing
on with its own task?  I think this is a big step backwards.  One of the things
I really like about ColdMUD is that all its network I/O is asynchronous.

> >   conn_object.parse()       => .connection_received(`[buffer])
> 
> Shouldn't this maybe just be .receive()?

Well, I was kinda trying to keep everything grouped together under a similar
naming convention..  maybe .connection_receive()..

> How about set_heartbeat_interval()?  Long, but it is after all what
> the thing actually does, unlike either of the above designations.

Ok by me..

> > Flexible builtin bindings
> 
> MOO and ColdMUD get more alike all the time.  It'll be interesting
> when/if CoolMUD gets in on this trend...

No, I'm talking about real flexibilty in builtin binding, not the kind of hack
that MOO is doing.

> >   Other contents/directories are allowed but ignored by the server.
> >   Logfile output will also be changed to go to stdout instead of stderr.
> >   stderr will be reserved for actual error messages.
> 
> This wouldn't work well with something like MOO's NP_SINGLE network
> module.

True, but ColdMUD doesn't have that.  If it did, or does in future, then under
that particular setup it would make sense to send everything to stderr instead,
but for other setups I don't see why we shouldn't take advantage of the two
streams and use them the way they were intended..

> The minimum here would be us-ascii characters, since everything in the
> server is expressed in terms of them, as well as all the internals of
> all current cores.  Strings should also IMHO never include newlines or
> vertical tabs/formfeeds (or the system-local equivalents of such).

Actually, the minimum, in my opinion, should be completely up to the particular
character set that the server is compiled to support.  Currently there is only
a US-ASCII based server, but there's no reason that one shouldn't be able to
convert it to being all EBCDIC (shudder) based if they wanted to.  It might
require a few language alterations, but there's no reason it couldn't do all
its internal processing in EBCDIC, save EBCDIC textdumps, etc.

> I'm not sure buffers should be nailed down as '8-bit bytes'.  
> Unicode-supporting systems should perhaps get 16.  I'm not entirely 
> certain of this, either.

No, this is exactly what I'm saying should _not_ be a consideration.  What a
buffer is or isn't should have absolutely nothing to do with what the data in
the buffer represents.  The 8-bit specification is simply to define how the
arbitrary bit pattern is broken up for processing and conversion to a text
representation when it's displayed, etc, and 8-bit is used because that's the
smallest breakdown commonly required for any binary data.

> This one is IMNSHO entirely silly, superfluous, and otherwise not a
> Good Thing(TM).  The idea behind it seems to be that by allowing
> online changing of methods basic to security one is undermining
> security.  However, if these methods cannot protect *themselves*
> from *unauthorized* changes I'd have pretty graves doubts about
> their general security myself.  The marginal security gain is simply
> not worth making a whole bunch of people crawl on their knees
> through textdumps when maintenance needs to be done.  The first
> thing I'd do if I found this bet set anywhere in a core DB would be
> to use a perl script to take all instances out.

Well, all I can say is you obviously have very little concept of proper
security in a computer environment.  I bet you have the same password on all
your MUDs and never change it too.  After all, if one system can't protect
itself against a cracker, well who cares about security anywhere on the
internet, then?

The simple point is that this level of added protection can't hurt and can make
holes (which will _always_ exist.  Anyone who thinks their software is
bug-free shouldn't be writing software) MUCH more difficult for someone to
exploit and/or hide their exploitation.

-R
-------------------------------------------------------------------------------
     Alex Stewart - riche@crl.com - Richelieu @ Diversity University MOO
              ftp://ftp.crl.com/users/ro/riche/html/riche.html