Subject: Random musings...

From: [email-masked]
Date: Thu, 10 Sep 1992 08:52:28 -0700

Well, since we now have server_log(), the "DISCONNECT" and "CONNECT"
messages can be moved into :disfunc() and #0:connect_player(), respectively.
"ACCEPT" and "CLINT DISCONNECTED" messages are harder to do...  What
about a :break_disfunc() which would be called if the player's link
goes dead by methods other than boot_player().  On a MOO like GodNet,
this could give finer distinction between quiting and losing one's link
accidentally -- additionally, "CLIENT DISCONNECTED" messages could move
into the database.  Actually, these changes are minor, probably worthless,
but it allows flexibility above the server level.

By the way, I am terribly glad that properties have been fixed, I've been
meaning to file bug reports and holler, but it's been done. :)  As to the
posting about changing the parent's properties and "dragging" all the
childrens' properties as well...  That is how it is supposed to be.  And
in theory, if an object has parents, it should not be used as a dynamic
object.   Thus, if you have a $shoe, you should only change $shoe.tied_lace
if you want the children to have the default value of $shoe.tied_lace
changed.  The same holds for verbs --  if you change a verb on a parent,
any non-shielded child will inherit the changes.

As far as chparent()'ing goes, I like blackbriar's model, but I do so
terribly hate to have the server calling verbs in the database...  This is
because the server should sit under the database, and not reach in and muck
with things... (It's unavoidable with things like .contents, .owner and flags)
I would like to keep the server in its place, as much as possible.  The
solution that comes to mind is to make a lot of server calls wizard-only
and write wrappers inside the db.  That way, the chparent() could be made
better, and the server doesn't interfere or make assumptions.

One last thing...  I wonder if it would be possible to have a makefile
switch called -DNOT_DISK_BASED which would keep the server in the old mode...
The reason I say this is because of a physical law of entropy, which in
computer science goes, "One trades space for cpu".  That is, if the server
is going to take less memory, you're going to use more cpu to manage the
space savings...  For some of us, memory is cheaper than cpu.  Also, I don't
know if short circuiting the swapping algorithm the OS provides is a good
thing.  What happens when you have your disk based server, and part of it
gets swapped, anyway? :)  If the swapping algorithm in the OS is broken,
then it should be fixed, not worked around.  I'll stop here, since I've
taken a lot of space, and this is probably a *very* unpopular view :) :)

Have fun.

---------
T. Pascal, King of Pascal          | "He travels fastest who travels alone,
1600 Campus Road, Box 829          | but not when the frost drops below zero
Los Angeles, CA 90041              | fifty degrees or more."
                                   |         -Old eskimo saying
       t_pascal@{{{cub,cheetah,jaguar}.math},tiger,cheshire}.oxy.edu

---

From: Matthew Jude Brown <[email-masked]>
Date: Thu, 10 Sep 1992 09:36:45 -0700

>taken a lot of space, and this is probably a *very* unpopular view :) :)

I don't think this [option to use the old server model] will be
necessary. I should imagine (having had a tiny bit of experience with
disk-based servers) that the cache size will be tuneable. If you've
got lots of memory, bump up the cache!  Make it large enough, and for
all practical purposes you'll be running memory-based.

'Short circuiting the swapping algorithm the OS provides', as you put
it, IS a good idea. Why? Simply that the OS's swapping algorithm is
horribly generic and knows little about the make-up of the data it's
working with. The MOO, on the other hand, knows what data is what, and
can therefore increase the likelihood of data being in core when it's
needed, with obvious speed improvements.

Problems will, of course, occur on systems where the MOO database is
held on slow disk - eg. on AFS. Here it's probably best to run with a
large cache in order to use the much faster local swap.

It has to be kept in mind that the OS swapping mechanism itself will
likely be much more rapid than any system the MOO itself can provide,
since the OS swaps in and out pages of about 4Kb a time, possibly
using much lower level disk access, and often to a dedicated local
swap device. In-server disk basing only wins if the increase in
caching efficiency more than counterbalances this.

-Morven/Matt

-- 
| Matthew J. Brown  | Dept. of Computing | If God intended for us to go to   |
| [email-masked]  | Imperial College,  | lectures He wouldn't have created |
| [email-masked] | 180 Queen's Gate   | double-sided photocopiers.        |
| Morven on Lambda  | LONDON SW7 2AZ     |          -IC RagMag 1991/92       |

---

From: [email-masked] (Jay A. Carlson)
Date: Thu, 10 Sep 1992 12:16:55 -0700

> messages can be moved into :disfunc() and #0:connect_player(), respectively.

:disfunc on what?