From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Message-ID: UniqueString: "<9011022356.AA06042@lambda.parc.xerox.com>"
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with
SMTP id <16500>; Fri, 2 Nov 1990 15:55:36 PST
Received: by lambda.parc.xerox.com
	(5.61+/IDA-1.2.8/gandalf) id AA06042; Fri, 2 Nov 90 15:56:32 PST
Date:	Fri, 2 Nov 1990 15:56:32 PST
From: pavel.parc@parc.xerox:com
To: MOO-Cows.parc@parc.xerox:com
Subject: Welcome to MOO-Cows!

I have created a new mailing list for MOO programmers, called
		MOO-Cows@Xerox.Com
The current membership comprises me (Lambda), Ghond, Frand, Gemba, and
Gary_Severn.  At some point in the near future, I'll announce it to
rec.games.mud, probably at the same time as I announce the general
availability of LambdaMOO.

As Gemba and Gary have already discovered, LambdaMOO has already
opened for initial building, debugging and universe-rules work.  The
address is lambda.parc.xerox.com (aka 13.1.101.87), port 8888.  Do not
be alarmed at any error you might receive by getting the port wrong;
it will likely tell you that there is no route to the host.  This is
due to our fancy network security set-up here; only packets destined
for port 8888 are let through to my machine.

The server is running what I am calling "gamma MOO", a heavily hacked
version of the beta MOO sources on belch.  The following is a partial
list of the changes I've made:

-- the MOO-code parser and interpreter have been largely rewritten to
allow easier extension of the language.  In particular, it is now
much easier to consider adding asynchronous tasks to the world (see
below for plans and status).

-- the following syntax has been added to allow iteration over
integers:
		FOR ident IN [expr..expr] stmts ENDFOR

-- the server no longer 'knows' what the parent-object of
newly-created players is, or where they start out.  It instead uses
the values of #0.player_class and #0.player_start.  I have begun using
#0 as 'the system object', on which many globally-useful values are
stored.  For example, in LambdaMOO, all of the useful public classes
are the values of appropriately-named properties on #0.  Thus, you can
say '#0.string_utils:match(...)' instead of using magic numbers.  In
effect, #0 has been made the only 'magic' number you need.

-- the syntax '$ident' has been added as an abbreviation for
'#0.ident'.  In addition, most of the built-in commands have been
hacked to recognize the syntax as well and to treat it appropriately.

-- tasks are now limited as to the number of expression-evaluations
they can do, 10000 at the moment.  Other CPU limit mechanisms may be
added when asynchronous tasks are enabled.

-- the '||' and '&&' operators now evaluate the right-hand side only
if necessary to determine the truth value of the expression as a
whole, just as in C.  Also, they return the value of the last
expression they evaluate, not necessarily 0 or 1.  Thus, the following
expressions now have the values indicated:
	17 || blah	==> 17
	0 || 17		==> 17
	1 && 17		==> 17
	"" && 17	==> ""

-- all case-sensitivity has been removed from the language.  The comparison
operators (==, >=, etc.) on strings, the 'index', 'rindex', and
'strsub' functions, and variable, property and verb lookup are all
case-insensitive.  The 'index', 'rindex', and 'strsub' functions all
take an optional final argument which, if true, makes them behave
case-sensitively. I intended to add a 'strcmp' function that does
case-sensitive comparison just like C, but I forgot.  I'll probably
add it later today.

-- everything that the server prints to stderr (log messages) is now
timestamped for maintainer convenience.

-- probably some other things that I don't remember right now...

==============

There are several changes already in the works, to be completed in the
next week or so:

-- I am changing all string- and list-indexing operations (i.e.,
foo[i], foo[i..j], 'index', 'rindex', etc.) to be one-based rather
than zero-based.  That is, {1, 2, 3}[2] will yield 2, not 3.  This
makes it easier to use the results of 'length(foo)' and 'x in foo' as
indices into foo.  In addition, I think it's probably more intuitive
for non-programmers.

-- I am adding the following syntax to create asynchronously-executed
tasks:
		FORK AFTER expr stmts ENDFORK
		FORK stmts ENDFORK
These forms queue up a task to execute the 'stmts' at some later time.
In the first case, the task executes in 'expr' seconds.  In the second
case, the task executes in 0 seconds.

Forked tasks are not guaranteed to be run exactly at the requested
time, but the server does its best to achieve this.  In almost all
cases, the delay should not exceed one or two seconds.  Since network
delays frequently take at least this long, the delays may not be
noticeable at all...

The local variables available to the forked task are exactly those
that had values when the FORK statement was executed, with exactly the
values they had at that time.  That is, variable assignments made
after forking are not seen by the forked task.

I have not yet worked out a satisfactory set of resource controls for
forked tasks.  They must prevent malicious forking of thousands of
tasks, but must also allow applications like robots and cuckoo clocks.
Suggestions?  I will probably enable forked tasks initially without
any controls.

The state of the forked-task queue WILL be saved in the database and
the server will 'catch up' on forked-task execution before accepting
commands from any network connections.

-- I'm adding an 'eval' function that takes a string, parses it as a
MOO verb body, and executes it.  It returns whatever the execution of
the body returns, just like a verb.

-- To make it convenient for programmers to evaluate expressions
and/or statements, I'm adding the ';' command as an abbreviation for
'eval ', just as '"' and ':' are handled now.

-- Adding several new functions giving access to everything necessary
to reimplement most of the built-in commands in MOO.  The major
exception for the time being is '.program' because it involves an
input-handling 'mode'.  I have serious ideas about bringing the parser
into MOO code, though, which would solve even this problem.

-- Adding a 'valid' function that takes an object and returns 0 or 1
depending on whether or not that object exists.

-- Adding a 'notify' function taking an object and a string; it does
what the built-in :tell verb does now and is only callable by wizards.

===========

Here are some other changes I'm considering.  Please feel free to
comment.

-- I currently use statements of the form
	"blah blah blah";
in order to include documentation in verbs.  I was even thinking of
having MOO code that automatically extracts such comments to make
programmer documentation, especially for library-like 'utils' objects,
like $string_utils.  Do we need/want a real comment construct as well?
If so, is it important that the server preserve comments to be shown
when you do a '.list'?

-- there are a whole lot of built-in properties right now, including
name, handles, location, and contents, that I'd like to change into
normal properties, maintained by the MOO code.

-- I want to move the MMO command parser entirely into MOO code.  The
right thing is probably to have a #0:process_command verb that
receives all of the arguments and then does whatever it wants.  In
particular, it should probably pass them off to a verb on the location
of the player, allowing one to do location-dependent parsing.  This
would allow things like the Loud Room in Zork (Adventure?) that just
echos everything you type until you type 'echo'.  It would also make
it possible to do 'moded' commands, like mail and gripes senders and
the .program verb, that need to have a persistent input mode for some
period of time.

Of course, doing this would slow down the system as a whole, but there
are two ways out of this.  The first is to radically improve the
performance of the interpreter; I believe that I could, with a moderate
amount of effort, make MOO code execute at least ten times faster than
it does now (if you're curious, this would involve compiling the code
into some linear instruction set and then super-optimizing the
instruction evaluator).  Another approach is to figure out where most
of the time is spent in the MOO version of the parser and recode those
parts in C as new built-in functions.

===========

Well, this message has gotten a whole lot longer than is appropriate
for a "welcome to the mailing list" note, so I'd better stop here.  I
look forward to seeing y'all on LambdaMOO and hearing back from you
concerning the suggested changes above.

	Lambda

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Message-ID: UniqueString: "<9011050008.AA07681@anu.anu.oz.au>"
Received: from anu.anu.oz.au ([130.56.4.1]) by alpha.xerox.com with SMTP id
<16561>; Sun, 4 Nov 1990 17:10:31 PST
Received: from PHYS.DECnet MAIL11D_V3 by anu.anu.oz.au (5.57/1.0)
	id AA07681; Mon, 5 Nov 90 11:08:13 EST
Posted-Date: Mon, 5 Nov 90 11:08:12 EST
Date:	Mon, 5 Nov 1990 08:08:12 PST
From: dxb105@phys.anu.oz:au
From:	dxb105@phys.anu.oz.au (David Bofinger)
To: "MOO-Cows.parc@parc.xerox.com"@anu:SMTP
Cc: DXB105@anu.anu.oz:au
Subject: Comments on what Lambda has done

>-- the following syntax has been added to allow iteration over
>integers:
>		FOR ident IN [expr..expr] stmts ENDFOR

Good! Is [-1,0] the null list? Should be...

>-- I am adding the following syntax to create asynchronously-executed
>tasks:
>		FORK AFTER expr stmts ENDFORK
>		FORK stmts ENDFORK
>These forms queue up a task to execute the 'stmts' at some later time.
>In the first case, the task executes in 'expr' seconds.  In the second
>case, the task executes in 0 seconds.
> 
>I have not yet worked out a satisfactory set of resource controls for
>forked tasks.  They must prevent malicious forking of thousands of
>tasks, but must also allow applications like robots and cuckoo clocks.
>Suggestions?  I will probably enable forked tasks initially without
>any controls.

How about limiting <CPU or easily measured facsimile thereof> per <small
period of time> for each player? The problem then is to decide who to "charge"
for a verb's activities. If you only charge the player, a programmer can write
a booby-trap verb that executes thousands of commands and bankupts the player.
Of course, that's not too serious if the allocation is for a very short time,
say a minute. If you only charge the programmer, a player can write a simple
verb that calls a fairly complex verb belonging to someone else thousands of
times. A rather complex compromise would be to charge the player for the first
<smallish allocation> on each player action, and the programmer(s) for the
rest. The smallish allocation would be more than adequate to run an exit, or a
say. I'm interested Lambda has chosen expression evaluations as a measure of
system resources, are they easy to measure?

While on the subject of control of system resources, what about control of
database bloat? I had some grandiose schemes for defining objects to be part of
"realms", and mass-recycling entire realms if they weren't used over an
extended period, after posting warnings.

>The state of the forked-task queue WILL be saved in the database and
>the server will 'catch up' on forked-task execution before accepting
>commands from any network connections.

I suppose you can always edit the database, if that's what caused it to crash?

>-- I currently use statements of the form
>	"blah blah blah";
>in order to include documentation in verbs.  I was even thinking of
>having MOO code that automatically extracts such comments to make
>programmer documentation, especially for library-like 'utils' objects,
>like $string_utils.  Do we need/want a real comment construct as well?
>If so, is it important that the server preserve comments to be shown
>when you do a '.list'?

You need two sorts of comments. The first I will call a "comment" :), and it
just gets ignored by the .program input mode. It's there so that you can quote
files verbatim through your client, without polluting the source code. The
second kind I will call "documentation", and that's what "blah blah blah", or
Frand's this:comment() is for.

I'm surprised Lambda hasn't mentioned his changes to the way exits work. I
don't see the point of throwing them all into #0. The major effect of the
change seems to be to make it difficult/ugly build an exit in a room one
doesn't own, whereas I would rather just require you to own the room it points
to (you can still make them of course, since Frand's classic "dive pile" still
works fine).Now that Gemba has modularised the look verb on rooms, it should be
easy to have the exits appear in a line of their own, distinct from the other
objects.

A change I'd like to see: rather than storing "player" and "caller", also keep
track of all the people it went through in between, ie have a list, probably
called "caller". This would simplify anti-spoofing (read: make possible) and
the accept verbs on rooms could just check whether one of their exits invited
the person in.

While I have the opportunity, I'd like to hassle Lambda for a rough map of the
house. I think we should settle on some basic configuration, including the
living room, closet, a corridor/hall, entrance hall and perhaps a staircase
with some landings. Once we have that, we'll have a coherent backbone we can
hang things off, and something to set the theme for the rest of the world.
Lambda mentions that you can have portals to different worlds sitting in
attics and whatever. I would like to keep that to a minimum, otherwise the
place will probably turn into a sort of quasi-nexus.
------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
		MOO:	Gary_Severn, Khamul
------------------------------------------------------------------------------ 

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com!pavel>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5713>; Thu, 8 Nov 1990 14:50:24 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16738>; Thu, 8 Nov 1990 14:49:08 PST
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <16742>; Thu, 8 Nov 1990 14:48:34 PST
Received: by lambda.parc.xerox.com
	(5.61+/IDA-1.2.8/gandalf) id AA01681; Thu, 8 Nov 90 14:48:18 PST
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.lambda.parc.xerox.com.sun4.40
          via MS.5.6.lambda.parc.xerox.com.sun4_40;
          Thu,  8 Nov 1990 14:48:17 -0800 (PST)
Illegal-Object: Syntax error in References: value found on alpha.xerox.com:
	References:	UniqueString: "<9011060837.AA00129@csc2.anu.oz.au>"
				    ^-illegal reference separator
X-NS-Transport-ID: 08002008D0FD00040A0C
In-Reply-to: "UniqueString: \"<9011060837.AA00129@csc2.anu.oz.au>\""
Message-ID: <EbCS2lAB0KJL86O0tX@lambda.parc.xerox.com>
Date:	Thu, 8 Nov 1990 14:48:17 PST
From:	Pavel Curtis <pavel@parc.xerox.com>
To:	MOO-Cows.PARC@xerox.com
Subject: Re: MOO ponderings...

Gemba talks about deciding where to put a verb and uses as one of his
examples a room that is right next to a jack-hammer, so 'say' doesn't
work there.  His solution, after postulating that the 'say' verb is
found on the player, is to put 'emote1' and 'announce' on the room, so
that they can be overridden by the room's programmer.

This strikes me as odd.  Won't a player who takes the trouble to
customize his 'say' verb just get annoyed in this loud room and rewrite
to use his own versions of 'emote1' and/or 'announce'?  What you really
want in such a case, it seems to me, is a slightly customized command
parser in that room.  It might just check for 'say' and do something
different only in that case, or else it might even decide not to
consider player-resident verbs at all.  Allowing this seems to me a more
flexible approach with many more applications.

Gemba then talked about my plans for a task-forking system and notes
that, if the verb-recursion limit is a part of the environment and if
the environment is copied for use by the forked task, then the forked
task can't be self-perpetuating, as a cuckoo-clock would require.  All
this is true, but the antecedent is false; the various CPU limits are
NOT in the environment that is copied for a forked task.  I must
apologize for lapsing into a use of programming-language semantics
jargon without flagging it.  The word `environment' here was intended to
me the names and values of the local variables.  That is, the forked
task gets to use the same variables as the parent task (though they
don't share assignments, as I explained before).  That's all, nothing
else is shared.  The forked task starts out with a different set of CPU
limits, though they may be derived in some way from those of the parent
at forking-time.

Gemba's remaining comments had to do with the increasingly-controversial
nature of my system for handling exits.  That issue deserves its very
own message, coming soon.

	Lambda


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Message-ID: UniqueString: "<9011060837.AA00129@csc2.anu.oz.au>"
Received: from csc2.anu.oz.au ([130.56.4.25]) by alpha.xerox.com with SMTP id
<16585>; Tue, 6 Nov 1990 00:37:18 PST
Received: by csc2.anu.oz.au (4.0/1.0)
	id AA00129; Tue, 6 Nov 90 19:37:04 EST
Date:	Tue, 6 Nov 1990 16:37:04 PST
From: tja105@csc2.anu.edu:au
From:	tja105@csc2.anu.edu.au ("Timothy J Allen")
To: MOO-Cows
Subject: MOO ponderings...

Thought I may as well afflict you all with my thoughts on various MOO-ish
matters. Firstly, which verbs should go where. The only sensible criterion
I've been able to come up with is that a verb should be on the object that
is most likely to want to change it. So most verbs should probably be on
the dobj or iobj, utility verbs that players need should be on the player,
and verbs that depend on the environment should be on the room. Can anyone
suggest any other important criteria? There is a fairly fine line between
the categories of verbs, however. Say, for example. Players might
conceivably want to customise their say verbs, eg they may prefer to hiss
or croak, or have a voice that reverberates around the room, or whatever.
On the other hand, the owner of the room should be able to specify that,
for example, the room is right next to an operating jack-hammer and you
can't hear anything that people say, or there is an echo and you hear
everything twice. In the case of say you can resolve this by putting
say on the player and emote1 & announce on the room. Actually, you may
as well put say on the fixture/thing, so it's bot-friendly, and use
this.name as the prefix instead of player. Then you may as well do away
with emote1.

In a more general case, how would you resolve this sort of conflict? Split
every verb up into parts on the player, parts on the room and maybe even
parts on the dobj and iobj, so they can all customize to their hearts'
content? Seems a bit heavy-handed. What was your rationale for putting
say and emote on the room, Ghond?

Lambda has split look up this way, and although I initially didn't like
the idea I now realize it has practical benefits. The look verb is now on
rooms, and it calls the look_self verb on objects as needed. This means
that the owner of the room can now declare a room dark, and stop you
from seeing anything, or say the room is full of hazy red smoke and prefix
every desc with "Through the hazy red smoke you can just make out", or
whatever. I think this is a good thing. However, should all verbs be
split this way?

Second rambling philosophization (is that a word? Does anyone care?). The
forking system that Lambda describes in his initial posting to this list
wouldn't, as far as I can gather, allow recurrent processes like cuckoo
clocks, because of the verb recursion limit. If the forked task executes
with the same environment it would have had if it had executed in the
verb from which it was forked, then presumably it keeps the same verb
recursion stack/counter/whatever. A working clock would need external
stimuli, such as people looking at it, to work.

I have a suggestion for a slightly different system that would actually
work. Instead of forking statements to be executed as though they were
executed within the current verb, schedule a call to a verb to be executed
as though a player had triggered it. Something like FORK object:verb args
AFTER time. Then you don't have the verb recursion problem and cuckoo
clocks work quite happily. Of course, the verb recursion limit would
act as a de-facto limit on task-forking in the present system, but I
think a more explicit and more useful limiting system would be better.

Regarding exits, I have to agree with David/Gary. I'm not terribly keen
on putting them all in #0 (or is it #-1? Whatever, same difference). You could
easily modify the look verb on rooms to identify exits and either list them
separately, or not list them at all, at the owner's whim.

I'd also like to reinforce Gary's plea for caller to become a list. Thus
caller[1] would be the same as caller now, and caller[length(caller)] would
be player. You could, but probably wouldn't want to, do away with the
player variable then. Anyway, the point is that making caller a list
would greatly ease the task of writing decent accept verbs. The use of move
instead of moveto solves some of the problems, but having a list of callers
would be better. Incidentally, is there now any point to the moveto verb?
Should it be done away with, or does it have some application?

That's all the ramblings for now. See yers later,
							Tim/Gemba
_______________________________________________________________________________
Tim Allen                                     tja105@csc2.anu.edu.au
Theoretical Physics
RSPhysS,ANU                     Don't woodchip the Lyman Alpha forest 

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <lambda.parc.xerox.com!pavel>
Received: from lambda.parc.xerox.com ([13.1.101.87]) by palain.parc.xerox.com with SMTP id <5712>; Thu, 8 Nov 1990 09:45:22 PST
Received: by lambda.parc.xerox.com
	(5.61+/IDA-1.2.8/gandalf) id AA01060; Thu, 8 Nov 90 09:44:21 PST
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.lambda.parc.xerox.com.sun4.40
          via MS.5.6.lambda.parc.xerox.com.sun4_40;
          Thu,  8 Nov 1990 09:44:20 -0800 (PST)
Message-Id: <YbCNZocB0KJL40wqMC@lambda.parc.xerox.com>
Date:	Thu, 8 Nov 1990 17:44:20 PST
From:	Pavel Curtis <pavel@parc.xerox.com>
To:	MOO-Cows@Xerox.Com
Cc:	pavel@parc.xerox.com
Subject: Re: Comments on what Lambda has done

[Note: This is a message that I first sent (or tried to send, anyway) a
couple of days ago.  Somehow, it never made it out of here.  I didn't
even get a copy myself!  Here's hoping for better luck this time...
--Lambda]

In reference to the new integer iteration construct, Gary asks, ``Is
[-1,0] the null list?''  I assume that by this he means, would the
statement ``FOR id IN [-1..0] stmt ENDFOR'' execute zero iterations? 
The answer is no, it would do one iteration for -1 and one for 0.  On
the other hand, ``FOR id IN [0..-1] stmt ENDFOR'' does indeed execute
zero iterations.

On the subject of resource limitation mechanisms, I'm not inclined to
implement anything very complex here; I'd much rather have something
reasonably effective that allows for a very simple user model.

I use expression evaluations as my measure at the moment because they're
really easy to count, one line of code at the top of the EVAL procedure.
 Ghond at one point suggested using a statement-execution count, but I
didn't think that they were as uniform a metric.

In reference to the notion that the queue of forked tasks will be stored
in the database, Gary asks, ``I suppose you can always edit the
database, if that's what caused it to crash?''  That was, inded, my
intent if no better scheme presented itself.  TinyMUD-2 does not store
its delayed-task queue in the database and so cannot support
intervention-free cuckoo-clocks and the like.  Also, I could imagine
building areas whose integrity depended upon having a guarantee that a
certain action would eventually be performed (like returning items to
their original places).  Unless the queue is saved on server shutdowns,
such guarantees can't be made.

Does anyone else agree with Gary that a dropped-by-the-parser,
non-persistent commenting construct is needed?  I'm inclined against it
on the theory that clients can simply run their code through something
like the C preprocessor before sending it down the wire.  On the other
hand, if you others think it's important, then I'd probably do it. 
Frand?  Gemba?

As to my new way of dealing with exits (that is, they are stored on the
.exits property of the room and have no interesting location), it seems
to me that it makes it more modular, not less, since it's easy to
override the look_self method on a whole class of rooms to have it print
a list of the exits, if you so choose.  I merely made the default be
that they're not printed.  I found this to be one of the desireable
features of TinyMUD, since you really had to read the descriptions in
detail in order to have a chance of solving puzzles, exploring the whole
place, etc.  You list of options wasn't just laid out in front of you. 
Of course, since it's so easy to have different behavior in your own
domain, you can feel free to do things differently there.

As to Gary's concern that this change makes it ``difficult/ugly build an
exit in a room one doesn't own,'' I think that this is the right thing. 
As the builder of the LambdaMOO house, for example, I'm much more
concerned about people building random exits off of arbitrary parts of
the house, thus messing up my conception of the layout of my domain.  In
comparison, I don't really mind as much if people make exits that dump
into parts of my domain.  I was considering taking a cue from the
UberMUD universe rules and making exits appear both on the .exits
property of the source and on the .entrances part of the destination. 
The exit would then check that this was, in fact, the case before
working.  This requires the maker of an exit to have the permission of
both ends before connecting them.  This seems an appropriate split of
concerns.  Of course, one would want to have some easy commands for
accomplishing such inter-realm linkage, but that's easy.

This also seems to address the major use Gary mentions for making
``caller'' a list, since it would no longer be necessary for `accept'
verbs to check that the player was entering via one of the room's
`approved' exits.

By the way, the reason I didn't mention this new arrangement in my first
note was that I wanted to stick to server changes there, keeping the
note from being LambdaMOO-specific.

Finally, Gary asks for a rough map of the house so that people can get
going in a coherent fashion.  Fair enough; here it is (thanks to Emacs
picture mode...):

             Front `Yard'


  --Garage
       |                         |       Powder Room          --MBR2...--??
       |                         |            |          down/
    Laundry   Dining Room---Entrance Hall--Corridor--Corridor  RR    Games
       |            |   ____/     |                     |  up\	|      |
       |            |  /          |                     |     Corr.--Corr.--??
  Family Room----Kitchen<----     |                  MBR1...   	|      |
       |            |        \    |                     |      Den   Guest
       |            |         Living Room---Closet      |
                                         \              |
                                          \------------Deck
                                                        |
                                                        |

                  Pool, Gardens

Only the leftmost seven rooms have been built so far; the rest of them
should be at least built, if not described, sometime today.  This is the
``currently-occupied'' part of the house, in which the current residents
actually live.  There is much, much more to the house that you and
others will build.  For the moment, I am only claiming the
currently-occupied part and the outside grounds.  The places for
building are as follows:

-- There will be an ironwork spiral staircase in the Family room going
both up and down.  The up direction is feebly blocked by one of those
museum-style velvet ropes, from which a sign hangs saying something
about how this marks the end of the currently-occupied part of the house
and how guests are advised that they continue past this point at their
own risk...  The down direction leads to the wine cellars used by the
residents and may also have exits beyond which building could take place.

-- Out the far end of the second master bedroom (MBR2), there will be
some kind of exit, probably another spiral staircase, perhaps hidden.

-- At the end of the upstairs corridor, there is another museum rope
with a similar sign.  Beyond that is an intersection with another
corridor, this one going north-south.  There will probably also be
another spiral staircase, hooking up with the one behind the second MBR
and continuing both up and down.

-- Out in the gardens, there may be room for several people to build
random bits.  I have no qualms with making the outside gardens rival Kew
Gardens in London for grandeur and variety.  There will certainly be
some kind of a hedge maze out there and whatever other weird stuff
people want to build.  (Anyone want to build a treehouse?)

-- I have no ideas about the front grounds right now.  As with the
gardens, one could conceivably find entrances to other parts of the
house as it rambles around in its piecemeal fashion.

-- There is this pool, see, and there just might be a hole somewhere at
the bottom of the deep end that led somewhere...

The idea for the MOO, suggest I think by Gary originally, is that the
house is a great, rambling, wildly inconsistent structure, built by many
people at many times in completely different architectural styles.  If
you've ever heard of the Winchester Mystery House, that's the general
idea.

To facilitate movement to distant parts of the house, I might build an
old-fashioned, hand-operated elevator.  Or perhaps underground somewhere
there used to be mining and so there's still the (somewhat unreliable)
coal train running down there, with occasional exits up into the house
above.  Maybe there are a few golf carts around for tooling about on the
grounds...  Or whatever.  You get the idea.

	Pavel


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <watcgl.waterloo.EDU!sfwhite>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5712>; Thu, 8 Nov 1990 22:35:00 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16772>; Thu, 8 Nov 1990 22:33:59 PST
Received: from watcgl.waterloo.edu ([129.97.128.64]) by alpha.xerox.com with SMTP id <16766>; Thu, 8 Nov 1990 22:33:04 PST
Received: by watcgl.waterloo.edu
	id <AA17534>; Fri, 9 Nov 90 01:22:59 EST
X-NS-Transport-ID: 08002008D0FD00040EBE
Message-ID: <9011090622.AA17534@watcgl.waterloo.edu>
Date:	Thu, 8 Nov 1990 22:22:59 PST
From:	Stephen White <sfwhite@watcgl.waterloo.EDU>
To:	MOO-Cows.parc@xerox.com, tja105@csc2.anu.edu.AU
Subject: Re:  MOO ponderings...

tim sez:

> In a more general case, how would you resolve this sort of conflict? Split
> every verb up into parts on the player, parts on the room and maybe even
> parts on the dobj and iobj, so they can all customize to their hearts'
> content? Seems a bit heavy-handed. What was your rationale for putting
> say and emote on the room, Ghond?

ummm, 'cos it worked?  :)  no real reason.

customization is well & good, but i have this nasty feeling cpu use
is going to rear its ugly head soon.  recall that chaos was shut
down for cpu use, not memory.  (after they switched to muck, which
has more searching & stuff).

someone oughtta run some benchmarks or something..

> Regarding exits, I have to agree with David/Gary. I'm not terribly keen
> on putting them all in #0 (or is it #-1? Whatever, same difference). You could
> easily modify the look verb on rooms to identify exits and either list them
> separately, or not list them at all, at the owner's whim.

#-1 should be a valid location now.  if/when .contents is converted to
a real moo-list, this will mean a memory saving over #0.  it's also
more idealogically pure.. they're "nowhere").  my idea with trashing
the 'invoke' function was that the room's "huh" function would handle
exits (the "huh" function gets called after all other matches fail)
by checking an .exits list on the room, and "go"ing to that exit, or
something.

> I'd also like to reinforce Gary's plea for caller to become a list. Thus
> caller[1] would be the same as caller now, and caller[length(caller)] would
> be player. You could, but probably wouldn't want to, do away with the
> player variable then. Anyway, the point is that making caller a list
> would greatly ease the task of writing decent accept verbs.

sounds reasonable to me.

> The use of move
> instead of moveto solves some of the problems, but having a list of callers
> would be better. Incidentally, is there now any point to the moveto verb?
> Should it be done away with, or does it have some application?

well, originally, the moveto() verb was so that bots and vehicles could
work without changing the invoke routines on exits, but i'm sure there
are ways to work around it.  it certainly is rather confusing for
new people.

the one advantage it does have is that there's no need to write move()
rules.. they're implicit in the accept() functions.  then again, it seems
like there're only a few useful accept() functions anyway.

stephen


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <csc2.anu.edu.au!tja105>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5712>; Fri, 9 Nov 1990 06:14:48 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16815>; Fri, 9 Nov 1990 06:13:30 PST
Received: from csc2.anu.oz.au ([130.56.4.25]) by alpha.xerox.com with SMTP id <16815>; Fri, 9 Nov 1990 06:12:22 PST
Received: by csc2.anu.oz.au (4.0/1.0)
	id AA02330; Sat, 10 Nov 90 01:12:06 EST
X-NS-Transport-ID: 08002008D0FD00041177
Message-ID: <9011091412.AA02330@csc2.anu.oz.au>
Date:	Fri, 9 Nov 1990 22:12:06 PST
From:	tja105@csc2.anu.edu.au ("Timothy J Allen")
To:	MOO-Cows.parc@xerox.com
Subject: Exits etc

Some thoughts about exits. I had a long whinge to Lambda about his exit
system after I managed to make the db inconsistent with a bungled attempt
at building, and suggested that the old system was more robust. The
reason the old system was more robust is that the .contents and .location
properties are hard-coded, so it's virtually impossible to subvert
them and make them inconsistent. This isn't true of Lambda's MOO-supported
.exits lists, which can be subverted quite easily and quite accidentally
in a number of ways. However, if/when Lambda gets around to supporting
the .contents and .location in MOO, rather than the server, the same
problem will arise, and probably much worse. If any programmer can write
a simple program that will make the db inconsistent, there is plenty of
scope for severe problems. Something has to be done about this beforehand,
and something has to be done about the exits also.

For the exits, making the dig and add_exit verbs more intelligent and
more robust would probably do. You'd want it really fool-proof. Maybe
the exits should be on properties of the room, rather than separate
objects. I'm not sure, but it's worth thinking about. One problem with
the present system is that if you recycle an exit, it doesn't disappear
from the exits list. If the exits weren't objects, that wouldn't happen,
though it might be difficult for people to remove exits they'd created
accidentally. Perhaps the room should keep track of who created the
exit and allow that person and the owner of the room permission to
delete/redirect/rename/change messages on the exit. If the only way
you can manipulate exits is via verbs on the room, then you can make
them completely watertight. The present system suffers from the exits
retaining the properties of objects. I think that if you don't want
the exits to be objects sitting in the room, you'd be better not having
them as objects at all. OK, so I am sure now, and it's definitely
worth thinking about. We also would then need some system for
determining who has the right to build an exit from a room. You could
let anyone build, on the understanding that the owner will delete an
exit if he/she doesn't like it, or at the other extreme you could only
let the owner build exits, but that's a bit of a pain for builders
who can't track down the owner of a room they want to build off. Easiest
would be, I suppose, for there to be a flag on the room that lets the
owner decide whether people can build exits from there, or maybe even
a list of people who are allowed to build exits. I'll have a go at
cobbling together a rough version of this notion and see how it goes.

For the contents and location props, you'd want something similar. ie,
only allow people to manipulate them via certain fairly low-level verbs.
Obviously, the owner of the room/object and wizards can manipulate
them directly, but presumably you can trust people not to bugger up
their own objects. There would be some interesting possibilities,
though, like people making themselves sit in two places at once, and being
able to hear two conversations (though probably not join in both of them
without some clever programming). In some cases this may be a good thing,
but it sounds like the sort of thing that could be abused; maybe there
should be some checking mechanism, though I can't see a practical one.
Maybe someone will think of one. I suspect it should be fairly easy to
make it so that you can only play games with omnipresence on your own
territory; that might be acceptable.

That'll do for now, I'll get on with trying to make some exits.

								Tim/Gemba


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <csc2.anu.edu.au!tja105>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5712>; Fri, 9 Nov 1990 07:50:16 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16820>; Fri, 9 Nov 1990 07:49:12 PST
Received: from csc2.anu.oz.au ([130.56.4.25]) by alpha.xerox.com with SMTP id <16819>; Fri, 9 Nov 1990 07:48:20 PST
Received: by csc2.anu.oz.au (4.0/1.0)
	id AA07683; Sat, 10 Nov 90 02:48:01 EST
X-NS-Transport-ID: 08002008D0FD0004122F
Message-ID: <9011091548.AA07683@csc2.anu.oz.au>
Date:	Fri, 9 Nov 1990 23:48:01 PST
From:	tja105@csc2.anu.edu.au ("Timothy J Allen")
To:	MOO-Cows.parc@xerox.com
Subject: exits again

Hello again folks. I've done what I said I'd do, and made a room with
exits implemented as I suggested in my last posting. It's #43, so move
yourselves there and have a look. It seems to work fine. Of course, a
bit more work needs to be done, adding front-end verbs etc, but it
basically looks fairly reasonable and robust. What do you think? You
have to use eval to add exits and set their messages at the moment, I'll
put front ends in later, but in the meantime you can add all the exits
you like using eval to try it out. The concept looks good to me, but of
course I'm biased 'cos I thought of it. How does it look to more
impartial observers? Is it worth changing all the exits to? I think
so, but that's just me :). The changeover would require a bit of work
on Lambda's part, so if he's convinced to do it my way I shall happily
volunteer to help do some of the exit conversion.

I think that once you've done away with exits as objects in the room,
you're better doing away with them as objects altogether. I think this
is what Stephen was hinting at in his posting(s). At least, that's
what got me to thinking along these lines.

A few other things need to be added, like build permissions on add_exit,
I'll do that soon too.

Let me know what you think.


					Tim/Gemba


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com!pavel>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5712>; Fri, 9 Nov 1990 18:28:10 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16944>; Fri, 9 Nov 1990 18:26:49 PST
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <16943>; Fri, 9 Nov 1990 18:25:55 PST
Received: by lambda.parc.xerox.com
	(5.61+/IDA-1.2.8/gandalf) id AA02824; Fri, 9 Nov 90 18:25:39 PST
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.lambda.parc.xerox.com.sun4.40
          via MS.5.6.lambda.parc.xerox.com.sun4_40;
          Fri,  9 Nov 1990 18:25:38 -0800 (PST)
X-NS-Transport-ID: 08002008D0FD00041A78
Message-ID: <0bCqIX0B0KJLQ6OBIs@lambda.parc.xerox.com>
Date:	Fri, 9 Nov 1990 18:25:39 PST
From:	Pavel Curtis <pavel@parc.xerox.com>
To:	MOO-Cows.parc@xerox.com
Subject: On permissions, movement, exits, and 'caller'

First off, let me apologize for taking so long to answer the various
messages I've received on the question of exits.  It has taken me this
long to get all of the issues (and there are a lot of them, as I hope to
make clear below) straight in my head.  I believe that, with the help of
Ford, a player who works right here with me and to whom I could
therefore have higher-bandwidth communication, I have gotten my head
around the problem and am ready to present that new understanding.  Here
goes...

At the bottom of the whole matter is the .location and .contents fields
and the fact that there are only a small number of ways to change them. 
There are, in fact, two ways to do so and I will argue that one of them
should be tightened up a bit and the other should be eliminated.

The first way to change something's .location is the built-in function
'move(what, where)'.  It currently performs the following test before
actually fiddling with .location and .contents (for the purposes of this
example, 'caller' is the owner of the verb containing the actual call to
'move'):

	(what.owner == caller
	 || what.location.owner == caller
	 || caller.wizard)
	&& where:accept(what)

That is, in order to successfully move what to where, you must either
own what or own where or be a wizard, and in any case where must allow
what to move there.

The second way to move something is to invoke the default
'moveto(where)' verb on that object (of course, it is entirely up to the
programmer of that object whether or not the default verb will be used).
 In this case, the first three lines of the test above are omitted; the
server merely checks that the destination will accept the object.

These are the only ways there are of moving an object.

If a wizard were to write a 'moveto' verb on the root object as follows:

	return move(this, args[1]);
then there would be no need for the default 'moveto' implemented in the
server.  <<I intend to make this change.>>

I contend that the second line of the test above, allowing you to move
any object that's inside something you own, is a bad idea.  In
particular, it means that I can't create a cursed sword that you can't
drop.  On the other hand, it does mean that I could create an immovable
object and drop it in your pristine room, and you couldn't get rid of it
unless I or some wizard helped.  For a primitive operation, I think I
choose to inconvenience the janitors rather than make an arguably-useful
object impossible to build.  <<I propose that the second line of the
above test be removed.>>

So, what we are left with is a primitive operation that allows you to
move anything you own to anywhere that will take it.  Simple enough.

But how do I write code to move something I don't own?  For example, how
do I make exits work (no matter how they're represented) since they need
to move the player?

You write code that politely asks the object to move itself.

This is the purpose of moveto verbs.  They are called from other verbs
who want the object to agree to move.  Implementations of 'moveto'
should make the decision about whether or not to let the object move
and, if so, call the 'move' function to accomplish the movement.  Note
that 'moveto' verbs should not bother calling the 'accept' verb on the
destination since 'move' will do that.

Therefore, almost all code will want to use
		what:moveto(where)
instead of
		move(what, where)
to acomplish movement.  In either case, that code will have to check the
location afterwards to see if the movement attempt was successful.

This brings up an important point.  Suppose I design a coke machine that
includes an object called a 'bottle'.  It has a moveto verb that only
lets it move to a player or into a trash can, printing some amusing
political note whenever littering is attempted.  Whenever I want to
dispense a coke, I create a new object whose parent is this primordial
bottle.  I also want to really give the bottle to the person who bought
it, so I change the owner to be that person.  This should all be
reasonable so far.

Now comes the problem.  Since the player owns the bottle, the 'moveto'
verb that I wrote can't accomplish the movement, since I'm (presumably)
not a wizard and I don't own the bottle.  Augh!

What's going on here is that I simply wanted to provide some code to the
player without requiring him to write it again and again for each
bottle.  Unfortunately, instead of this inherited code running with the
bottle-owner's permissions, it's running with mine.  The fix seems
clear: let me set a bit on the verb to say that it should run with the
permissions of 'this', object that inherited the verb.  <<I propose
adding such a bit to the permissions-set of all verbs, defaulting to
'off' for compatibility.>>

OK, so now we understand movement and permissions a bit better.  Let's
go on to exits.

I have seen three implementations of exits in MOO:

-- an exit is an object with a .dest field that sits on the .contents
list of its source and has an 'invoke' verb that does the movement. 
This is how the AlphaMOO on belch worked.

-- an exit is an object as before, but it sits on the .exits list of its
source and does not, therefore, show up on the description of the room. 
This is how most of LambdaMOO works right now.

-- every room maintains several lists in parallel holding the names,
destinations, and cute messages associated with each of its 'exits'. 
The 'huh' verb on the room now does the exit processing itself, without
the use of any other objects.

When it comes right down to it, there really isn't a great deal of
difference between these three representations and, with a certain
amount of work, each could be hacked to have all of the advantages of
the others.  (I must say, though, that I think the difference in
functionality between the last two is particularly small; the second is
somewhat more convenient to work with since you don't have to deal with
all of those parallel lists.  But I digress...)

In all cases, they call the 'moveto' verb on the player to accomplish
the movement, as discussed above.

The major argument about exits, though seems to center on two questions:

-- What is involved in my adding an exit from/to a room that I don't own?

-- How can I restrict access to a room so that it comes only through one
of my approved entrances?

The first question is actually a bit odd, since there isn't really
anything special about exits, right?  I mean, any object can have a verb
on it that (tries to) move the player somewhere, so I could just drop
that object in your room (which, in practice, your room's accept verb
will probably allow) and let people leave your room by playing with my
object.  As to exits whose destination is your room, that's really part
of the second question.

No, the first question is really this: what's involved in my adding an
exit from your room that appears to be a part of the normal topography
of the place?  The answer, now, is clear: you don't add the exit
yourself, you get me to do it.  (Alternatively, I allow anyone to add an
exit to my room if I'm so inclined.)

As to the second question, it is easy to see from the discussion of
movement above that everything comes down to writing an accept verb that
really works.  Several people have asked for 'caller' to be a list so
that they can write an 'accept' verb that is dsicriminating.  They would
like to check, for example, that the object being moved to the room is
being moved via an approved exit.  So, they say, they'll just check that
callers[2] is that exit.  (Recall, please, that the accept verb appears
to be called from the verb that called 'move', which is not on the exit
but is the 'moveto' verb of the object itself.)

But this is the crux of the whole matter!  How do you KNOW that the exit
is callers[2]?  My 'moveto' verb might make an arbitrary number of calls
before getting around to calling 'move', right?  I suppose that you
could look up the entire list of callers to see if your approved exit is
anywhere on the call-stack, but this seems like very dirty programming
to me, and anything but a sure thing.

Instead, I offer something much that's simpler and entirely reliable. 
Have your approved exit, just before calling the object's 'moveto' verb,
call the destination's `bless_for_entry' verb with the object as an
argument.  The room then checks that the caller of that method is an
approved exit.  If so, it remembers the argument in a property on the
room.  When the accept verb is called a moment later, the room tests to
see if the argument is currently blessed and, if so, allows the
movement.  Finally, after calling the 'moveto' verb on the object, the
exit again calls the room, telling it to 'unbless_for_entry' the object.

While this sounds like a lot of mechanism, it can easily be packaged up
once and then used everywhere.  As I said before, it's entirely reliable
and unspoofable.  Or is it?  Suppose that execution aborts for some
reason after the object was blessed but before it was unblessed?  It
would remain on the blessed-list of the room with free access from then
on!  One fix, off the top of my head, is to add a language construct
like the following:

	WITH obj.prop = expr
	   stmt
	ENDWITH

which is equivalent to this:

	old_value = obj.prop;
	obj.prop = expr;
	stmt;
	obj.prop = old_value;

except that it guarantees that obj.prop will get reset to its old value
even if execution of 'stmt' aborts.

Whew!  This is a lot of stuff to think about, but I think that it lays
out the issues more clearly than has been done before.  Please let me
know what you think and we'll implement whatever we agree upon.

	Lambda

PS- I found and fixed the bug that caused the recent crashes on
LambdaMOO.  If it crashes now, it will have to do so for a new reason...


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <csc2.anu.edu.au!tja105>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5712>; Fri, 9 Nov 1990 20:19:00 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16945>; Fri, 9 Nov 1990 20:17:52 PST
Received: from csc2.anu.oz.au ([130.56.4.25]) by alpha.xerox.com with SMTP id <16944>; Fri, 9 Nov 1990 20:16:59 PST
Received: by csc2.anu.oz.au (4.0/1.0)
	id AA21102; Sat, 10 Nov 90 15:13:21 EST
X-NS-Transport-ID: 08002008D0FD00041B33
Message-ID: <9011100413.AA21102@csc2.anu.oz.au>
Date:	Sat, 10 Nov 1990 12:13:21 PST
From:	tja105@csc2.anu.edu.au ("Timothy J Allen")
To:	MOO-Cows.parc@xerox.com
Subject: movement and exits

>Lambda says:
>[let the owner of the object move it, no-one else, to allow things like cursed
swords etc, and use moveto to request movement]

Sounds reasonable. The cursed-sword motivation doesn't hold up, because if
you're implementing some sort of frp system it's impractical to rely on
properties of the player to store adventure-related information, you have to
do that in your own database (that's what my adventurer's database, #46, is
for). So you can easily keep track of the fact that a player has a cursed
sword, and even if he/she drops it, next time he tries to do anything
combat related he mysteriously finds the sword back in his hand. Perhaps
the janitor problem is worth thinking about after all.

Another way of implementing undroppable items is to have a standard hook in
enterfuncs on all rooms, that an object can trap to notice it's been dropped,
and do something as a result of being dropped (aka drop, odrop, adrop in
Tiny*), such as give itself back to the player.

Anyway, this is just being pedantic, really. Lambda's notions sound reasonable,
apart from the garbage problem. Always using moveto on the objects is
ideologically purer, from an object-oriented point of view. Re the garbage
problem, maybe there should be a recycle-on-sight policy for immovable
objects, and maybe for their owners if they persist. A wizard could easily
write a janitor-bot that would run with wizard permissions to clean up
excessive junk, providing some useful criterion for what is excessive junk
can be found.
>
>Therefore, almost all code will want to use
>		what:moveto(where)
>instead of
>		move(what, where)
>to acomplish movement.  In either case, that code will have to check the
>location afterwards to see if the movement attempt was successful.
>
>This brings up an important point.  Suppose I design a coke machine that
>includes an object called a 'bottle'.  It has a moveto verb that only
>lets it move to a player or into a trash can, printing some amusing
>political note whenever littering is attempted.  Whenever I want to
>dispense a coke, I create a new object whose parent is this primordial
>bottle.  I also want to really give the bottle to the person who bought
>it, so I change the owner to be that person.  This should all be
>reasonable so far.

This just won't happen. A vending machine that sells you things belonging
to you will sell you trojan horses. If you accept something sight unseen,
or verbs unseen, that will run with your permissions, you're asking to have
all your objects recycled at the very least. If you think it won't happen,
you're wrong. Vending machines will have to retain ownership of the things
they sell, and some way of enforcing that will have to be devised, or
vending machines mustn't be allowed at all.
>
>Now comes the problem.  Since the player owns the bottle, the 'moveto'
>verb that I wrote can't accomplish the movement, since I'm (presumably)
>not a wizard and I don't own the bottle.  Augh!
>
>What's going on here is that I simply wanted to provide some code to the
>player without requiring him to write it again and again for each
>bottle.  Unfortunately, instead of this inherited code running with the
>bottle-owner's permissions, it's running with mine.  The fix seems
>clear: let me set a bit on the verb to say that it should run with the
>permissions of 'this', object that inherited the verb.  <<I propose
>adding such a bit to the permissions-set of all verbs, defaulting to
>'off' for compatibility.>>

I'm not quite sure I follow this bit. Are you saying that at the moment, if
I create an object giving ownership to someone else and then run a verb on
that object, the verb will run with my permissions? If that is what happens,
it sounds nonsensical and should obviously be changed, so I presume you
mean something else. Anyway, I shouldn't be allowed to create an object
belonging to someone else or I can make trojan horses. Perhaps wizards
could be allowed to do that, but no-one else.
>
>OK, so now we understand movement and permissions a bit better.  Let's
>go on to exits.
>
>I have seen three implementations of exits in MOO:
>
>-- an exit is an object with a .dest field that sits on the .contents
>list of its source and has an 'invoke' verb that does the movement. 
>This is how the AlphaMOO on belch worked.
>
>-- an exit is an object as before, but it sits on the .exits list of its
>source and does not, therefore, show up on the description of the room. 
>This is how most of LambdaMOO works right now.
>
>-- every room maintains several lists in parallel holding the names,
>destinations, and cute messages associated with each of its 'exits'. 
>The 'huh' verb on the room now does the exit processing itself, without
>the use of any other objects.
>
>When it comes right down to it, there really isn't a great deal of
>difference between these three representations and, with a certain
>amount of work, each could be hacked to have all of the advantages of
>the others.  (I must say, though, that I think the difference in
>functionality between the last two is particularly small; the second is
>somewhat more convenient to work with since you don't have to deal with
>all of those parallel lists.  But I digress...)

You seem to be missing the point of my efforts here. The second system has
severe problems because mere mortals can corrupt it. The difference in
functionality is precisely a minimalization of the possibility for
database corruption. Having exits as pseudo-objects has problems because
of the properties of objects; eg they can be recycled without the
corresponding exits lists being updated, they can come adrift completely,
and I'm sure there are other problems. If you don't want exits to be
objects sitting in the room (and I am now convinced that it's better if
they're not), then it's more elegant, robust and simple to not have them
as objects at all. Dealing with "all those parallel lists" isn't a
problem. Look at my verbs on #43, they're not complicated, but they do all you
need to do to handle exits. Incidentally, I've added a build_ok flag the
owner can set to allow or deny other people building exits in his/her room.
>
>
>The major argument about exits, though seems to center on two questions:
>
>-- What is involved in my adding an exit from/to a room that I don't own?
>
>-- How can I restrict access to a room so that it comes only through one
>of my approved entrances?
>
>The first question is actually a bit odd, since there isn't really
>anything special about exits, right?  I mean, any object can have a verb
>on it that (tries to) move the player somewhere, so I could just drop
>
>No, the first question is really this: what's involved in my adding an
>exit from your room that appears to be a part of the normal topography
>of the place? 

True. Anyone can drop an object that moves people, but the owner of the room
has control over what the room's huh verb is prepared to look at, and
hence over which exits will appear as natural ones.

>The answer, now, is clear: you don't add the exit
>yourself, you get me to do it.  (Alternatively, I allow anyone to add an
           ^^^^^^^^^^^^^^^^^^^
And are you going to type in my 3000 characters of leave, arrive and fail
messages for me? I'm certainly not volunteering to do that for anyone
who wants an exit off anywhere I build. I think the solution I've
implemented (again, it's my idea, so I'm attached to it :)) is better,
the owner of the room decides whether people can build there, and if
they can, then the builder makes the exit and has the right to set and
change the various messages attached to the exit.

>exit to my room if I'm so inclined.)
>
>As to the second question, it is easy to see from the discussion of
>movement above that everything comes down to writing an accept verb that
>really works.  Several people have asked for 'caller' to be a list so
>that they can write an 'accept' verb that is dsicriminating.  They would
>like to check, for example, that the object being moved to the room is
>being moved via an approved exit.  So, they say, they'll just check that
>callers[2] is that exit.  (Recall, please, that the accept verb appears
>to be called from the verb that called 'move', which is not on the exit
>but is the 'moveto' verb of the object itself.)
>
>But this is the crux of the whole matter!  How do you KNOW that the exit
>is callers[2]?  My 'moveto' verb might make an arbitrary number of calls
>before getting around to calling 'move', right?  I suppose that you
>could look up the entire list of callers to see if your approved exit is
>anywhere on the call-stack, but this seems like very dirty programming
>to me, and anything but a sure thing.

True, using caller that way might be a bit fragile, unless some fairly
rigid convention for how movetos work is established.

>Instead, I offer something much that's simpler and entirely reliable. 
>[Lambda outlines a bless_for_entry verb]
>While this sounds like a lot of mechanism, it can easily be packaged up
>once and then used everywhere.  As I said before, it's entirely reliable

One point here, which probably stems more from my ignorance of how the
forking system works than from any real concerns. What happens if a forked
task that's going to call an exit runs at that time? Is that possible?
Do forked tasks run concurrently with other tasks, or do they wait until
no other task is running?

>[description of an extension to the language that would make the scheme
>more robust against crashes]

The basic notion of a bless_for_entry verb sounds reasonable, despite the
fragility of it with respect to crashes etc. The use of a caller list might
not be reliable as a way to determine entry permissions. The other
potential use for a caller list was in anti-spoofing. At the moment, anti-
spoofing doesn't work reliably. I haven't worked out a scheme that would work
with a caller-list, but I'm sure one could be devised.

>
>Whew!  This is a lot of stuff to think about, but I think that it lays
>out the issues more clearly than has been done before.  Please let me
>know what you think and we'll implement whatever we agree upon.

Yes, thanks, this is something we need to get sorted out before major
building in your house starts.

>	Lambda
>

		Tim/Gemba


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <anu.anu.oz.au!guest>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5712>; Sat, 10 Nov 1990 16:53:51 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <17065>; Sat, 10 Nov 1990 16:53:15 PST
Received: from anu.anu.oz.au ([130.56.4.1]) by alpha.xerox.com with SMTP id <17063>; Sat, 10 Nov 1990 16:52:19 PST
Received: by anu.anu.oz.au (5.57/1.0)
	id AA13570; Sun, 11 Nov 90 11:48:28 EST
Posted-Date: Sun, 11 Nov 90 11:48:28 EST
X-NS-Transport-ID: 08002008D0FD00041FF9
Message-ID: <9011110048.AA13570@anu.anu.oz.au>
Date:	Sun, 11 Nov 1990 08:48:28 PST
From:	dxb105@phys.anu.oz.au (David Bofinger)
Sender: guest@anu.anu.oz.au
To:	mc@anu.anu.oz.au
Subject: Exits et cetera

Wow, come back from a bushwalk and I log in to find ~5 MOO messages.As part of
my campaign to have pronouns put back into MOO, I will be using .p* to
represent them in this message.

>At the bottom of the whole matter is the .location and .contents fields
>and the fact that there are only a small number of ways to change them. 
>There are, in fact, two ways to do so and I will argue that one of them
>should be tightened up a bit and the other should be eliminated.

These are move(,), moveto(). But what about changing them directly? Weren't you
going to implement them in MOO code? May be danger....

>	(what.owner == caller
>	 || what.location.owner == caller
>	 || caller.wizard)
>	&& where:accept(what)

I'm mildly surprised Wizards can get stymied by accept verbs, not that it
really matters.

>I contend that the second line of the test above, allowing you to move
>any object that's inside something you own, is a bad idea.  In
>particular, it means that I can't create a cursed sword that you can't
>drop.

What if I make a cursed sword, or, more likely, something with an obscene name,
and give it to someone so they can't get rid of it? Even after they leave my
dungeon? Or even before they enter it? Cursed swords are probably better
implemented by maintaining a voodoo doll of the character (an object with
adventure related attributes), and accepting that players have total
sovereignty. If a player quits your dungeon you can't stop .po. But you can
blacklist .po, which is good enough.

>  On the other hand, it does mean that I could create an immovable
>object and drop it in your pristine room, and you couldn't get rid of it
>unless I or some wizard helped.

Lambda, I think this is _very_ _important_. How do others feel about the
relative importance of these pros and cons?

>So, what we are left with is a primitive operation that allows you to
>move anything you own to anywhere that will take it.  Simple enough.

Yep.

>But how do I write code to move something I don't own?  For example, how
>do I make exits work (no matter how they're represented) since they need
>to move the player?
>You write code that politely asks the object to move itself.

Not quite. Lots of times I want to order the object to move somewhere, or, in
the case of delittering, anywhere,  whether .ps wants to or not. Rather, write
code that politely asks the room to move the object for you. The room is
guaranteed to have the privelige. The room decides whether it trusts you that
much or not.

Here's how it works:

player: types "north". There's no north on the room or player, so
  room:huh checks for objects, and finds one. So it calls the invoke verb on
		that. In this particular case, we'll assume the object is an
		exit.
    exit:invoke checks the player's ID, and concludes that he's an upstanding
		fellow the exit would be proud to have pass through it. So it
		asks the room it's in if it would, please, send this fellow to
		where he would like to go.
      room:movethingto checks that (a) the player actually is in the room, (b)
		that an approved exit is making the request. If they say yes,
		it does its best to send the fellow to destination, by calling
		move().
	destination:accept checks that the person is wanted here. It might
		check who is making the request, for instance, are they part of
		my realm? Or it might check the player's sex is that of the
		toilet it is. Let's say it says yes.
	room:exitfunc announces player's departure. Before doing that, it has
		to call:
	  exit:success_msgs_verb, which tells player and any observers what the
		player has done. It would be much prettier if this happened
		later, see below. It has to do a bit of searching to find the
		exit, at this stage.
	destination:enterfunc announces player's arrival, does a look, etc.
      room:movethingto gets the code "successful move" back from the move().
    exit:invoke would like to give the player a few messages, but it's a bit
		late now. This is the least elegant part of the procedure. If
		the move were a failure, or never called for some other reason,
		then it would call failure messages.
  room:huh has nothing to do.

Are there any holes in this? It may seem a bit complicated, but as Lambda said
in a differeny context, it need only be written once. Notice that each level
has to be robust: teleport verbs will call move(,) directly, for instance, so
destination:accept has to be able to cope with that possibility.

>This brings up an important point.  Suppose I design a coke machine that
>includes an object called a 'bottle'.  It has a moveto verb that only
>lets it move to a player or into a trash can, printing some amusing
>political note whenever littering is attempted.  Whenever I want to
>dispense a coke, I create a new object whose parent is this primordial
>bottle.  I also want to really give the bottle to the person who bought
>it, so I change the owner to be that person.

Uh-oh.

>This should all be reasonable so far.

Isn't, sorry. I think Gemba explained why not, but do the words "Trojan Horse"
mean anything to you? What you have created is a gadget with the privileges of
its new owner but following the instructions of its old. Very, very dangerous.

>I have seen three implementations of exits in MOO:
>-- an exit is an object with a .dest field that sits on the .contents
>ist of its source and has an 'invoke' verb that does the movement. 
>This is how the AlphaMOO on belch worked.

I still like this one best, sorry.

>-- an exit is an object as before, but it sits on the .exits list of its
>source and does not, therefore, show up on the description of the room. 
>This is how most of LambdaMOO works right now.

Its trivial to stop exits appearing on the "contents" description. Give them a
flag, or something. Some people may _want_ them to appear there, anyway, so
that could be negative values of ctype.

>-- every room maintains several lists in parallel holding the names,
>destinations, and cute messages associated with each of its 'exits'. 
>The 'huh' verb on the room now does the exit processing itself, without
>the use of any other objects.

Ugh. Well, it works, but the exits  become rather inflexible beasts, because
you can't create new classes of exit. Gemba points out you can still
instantiate new classes of room that have different exit behaviour, but by
Fubar its ugly.

>The major argument about exits, though seems to center on two questions:
>-- What is involved in my adding an exit from/to a room that I don't own?
>-- How can I restrict access to a room so that it comes only through one
>of my approved entrances?

>No, the first question is really this: what's involved in my adding an
>exit from your room that appears to be a part of the normal topography
>of the place?

Under the system I described above, simply set the accept verb on a room to
refuse to admit things with an exit flag set, unless they are mentioned in the
permitted exits list. Actually, you also have to occasionally eject illegal
exits, because they might have had their flag set after they entered. Make that
part of the look verb, I suppose.  Notice that unsanctioned exits can't use
room:movethingto(,), they have to settle for thing:moveto().

>[discussion of how not to make room:moveto type exits work.]

>Instead, I offer something much that's simpler and entirely reliable. 
>Have your approved exit, just before calling the object's 'moveto' verb,
>call the destination's `bless_for_entry' verb with the object as an
>argument.  The room then checks that the caller of that method is an
>approved exit.  If so, it remembers the argument in a property on the
>room.  When the accept verb is called a moment later, the room tests to
>see if the argument is currently blessed and, if so, allows the
>movement.  Finally, after calling the 'moveto' verb on the object, the
>exit again calls the room, telling it to 'unbless_for_entry' the object.

Yes, I thought of this possibility. It would work now, but I am concerned about
the effect forking will have on it.
------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
		MOO:	Gary_Severn
------------------------------------------------------------------------------
"Are you listening Bog? Is a computer one of your creatures?" -R.A. Heinlein


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com!pavel>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5713>; Mon, 12 Nov 1990 17:40:11 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <17193>; Mon, 12 Nov 1990 17:38:29 PST
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <17193>; Mon, 12 Nov 1990 17:37:26 PST
Received: by lambda.parc.xerox.com
	(5.61+/IDA-1.2.8/gandalf) id AA05539; Mon, 12 Nov 90 17:36:52 PST
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.lambda.parc.xerox.com.sun4.40
          via MS.5.6.lambda.parc.xerox.com.sun4_40;
          Mon, 12 Nov 1990 17:36:51 -0800 (PST)
X-NS-Transport-ID: 08002008D0FD00042E15
Message-ID: <QbDosnYB0KJLEItnpF@lambda.parc.xerox.com>
Date:	Mon, 12 Nov 1990 17:36:51 PST
From:	Pavel Curtis <pavel@parc.xerox.com>
To:	moo-cows.parc@xerox.com
Subject: Movement and exits, round 2

All this discussion is great fun, but it sure does take a lot of time to
read all of that mail... :-)

Gary asks whether or not I was planning to move the .contents and
.location attributes into MOO code (thus allowing them to be changed
directly) and wouldn't that be dangerous?  The answers are yes and it
depends on how you do it.  My intent was (eventually!) to make them
normal properties that are owned by the wizard and not writable and not
'children-inherit-ownership' (or whatever the 'c' permissions bit stands
for...).  Except for the fact that .location and .contents would be
readable, this is just like the .password property in LambdaMOO now. 
Thus, you can control modification of the fields to maintain consistency.

Gary is mildly surprised that wizards can be stymied by :accept verbs. 
So was I, and I may change that soon unless anyone can think of a reason
not to.  Anyone?

On the subject of my desire to remove the ability for anyone to move an
object that's in a location they own, I mentioned that having this
ability made it impossible to make undroppable objects.  Gary doesn't
seem to like the idea of undroppable objects in the first place, since
someone could make something really objectionable and then just give it
to you.  My answer to that is to say, ``Perhaps you need a better, more
picky :accept verb...''.  I was thinking, for example, that I wouldn't
mind having an :accept verb on me that refused unless player == me. 
Then, of course, nobody could give me anything, but that seems better to
me as a default.  Perhaps we can work out a reasonable 'give' convention
that lets both players have a say in whether or not the transfer
succeeds.

On the same subject, Gemba says that the cursed-sword motivation doesn't
hold up, but I couldn't follow his reasoning.  Gemba, you said correct
stuff about how you can't use player properties to keep track of
realm-specific stuff (thus, your Adventure Database), but you didn't
relate that to the cursed-sword issue, which doesn't depend on player
properties at all...

Of course, as I mentioned in my previous note, there is this littering
problem that arises if the move() function's check is changed as I
suggest.  That is, someone could drop some immovable object in your room
and then you can't get rid of it.  My fix here, like something Gemba
suggested but less radical, is for a wizard to write a verb on all rooms
(or perhaps players) that allows the owner of a room to eject items
(into the Garage?  That could be fun...).

Both Gemba and Gary, being more experienced/paranoid than I am, pointed
out that the ownership-changing part of my coke machine example implies
a major Trojan Horse security hole.  Talks with Ford convinced me that
the whole point of that example, a permissions bit on verbs letting them
execute with the permissions of the child object who inherited the verb,
is also a big problem.  Consider the idea dropped.  It's always a shame
when things that could be used for good purposes must be scrapped in
order to protect against nasty people.  Sigh.

Gemba objected to my preference for the current implementation of exits
in LambdaMOO over his experimental one.  He said that his mechanism
avoided problems of ``corruption'' by ``mere mortals''.  The only type
of corruption that he mentions is that of recycling an exit without
first removing it from the '.exits' list.  I don't think that we can
solve this problem by trying to patch around it for exits; it's a
problem whenever you put a reference to some object in some other
object, something we do all of the time.  I think that the best level of
automatic help for this comes in two parts, one already implemented, one
now on my `To Do' list:

-- Give programs a way to test for whether or not an object has been
recycled.  There is now a function 'valid(object)' that returns true if
and only if 'object' currently exists.

-- Stop reusing the object numbers of recycled objects.  Right now, if I
recycle an object and then immediately create a new one, the new one
will have the same object number as the recycled one.  This is a
particularly nasty problem, since I could recycle something and forget
to take it off some list of ``privileged'' objects.  Now somebody else
creates an object which gets that very same number and now even 'valid'
can't help me.  We do, after all, have 2 billion numbers to use up. 
That's really a very, very large number.  There's no need to reuse them.
 [I haven't yet looked at what's involved in backing out this feature,
but it can't be very hard.]

My biggest problem with Gemba's representation, though, is that it makes
subclassing exits a real pain.  I have to subclass the room instead and
then I have to change almost every verb in order to get things back to
normal.  Further, the implementation of rooms is jumping through hoops
to emulate everything that exit-objects would provide, including
ownership, various properties, etc.  Objects can do this emulation a
whole lot better.

Gary still likes the old, AlphaMOO style of representation.  I don't
think that we've given anything up here over that style and we've
instead gained some programming convenience.  He mentions that he misses
`look south' working; I think he must not have tried it in LambdaMOO,
since it has always worked there.  The 'look' and 'describe' verbs use a
common mechanism that includes the .exits list in the search for matches.

On the subject of adding exits from a room you don't own, I suggested
that you don't do so; instead, you get the owner of the room to add it
for you.  Gemba objects, saying that he doesn't want to type in all 3000
bytes of cute messages for people who make exits from his rooms.  What
should you have to?  I create the exit in limbo, fix up all of the
messages and then get you to put it on your room's .exits list.  I
realize that the 'dig' verb isn't properly modularized for this now, but
that's easy.  Since the owner of the exit still owns it, he/she can
still muck around with the properties even after it's been linked up.

Both Gary and Gemba were concerned about the possible interaction
between my 'blessing' architecture for controlled entrance to rooms and
the new forked-task facility.  Relax.  Forked tasks have the same
running behavior as normal command-spawned tasks: each task runs to
completion (or abort) before any other task runs.  The very notion of
letting true concurrency into this code turns my hair white; the
fragility of the blessing architecture in the face of concurrency is
just the tiniest tip of the iceberg.  Almost all of the MOO code in the
universe would be broken in the presence of parallelism.

Finally, Gemba once again brings up what appears to be one of Gary's
favorite causes: making 'caller' a list to allow ``anti-spoofing''. 
Could one of you PLEASE write down in detail just what you're worried
about here, just why the current .paranoid flag isn't sufficient, and
just how a 'caller' list would help?  In detail.  Please?  I'm really
not interested in making the necessary changes without a detailed idea
of why it's any use.

Whew!  I think/hope we're nearing concensus here.  I certainly hope so,
since I want to get more building under way!

	Lambda


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <rsphy1.anu.edu.au!tja105>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5713>; Mon, 12 Nov 1990 18:35:46 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <17193>; Mon, 12 Nov 1990 18:34:37 PST
Received: from rsphy1.anu.edu.au ([130.56.5.113]) by alpha.xerox.com with SMTP id <17196>; Mon, 12 Nov 1990 18:33:28 PST
Received: by rsphy1.anu.edu.au (5.57/Ultrix3.0-C)
	id AA06106; Tue, 13 Nov 90 13:31:49 -1000
X-NS-Transport-ID: 08002008D0FD00042EB2
Message-ID: <9011132331.AA06106@rsphy1.anu.edu.au>
Date:	Tue, 13 Nov 1990 15:31:49 PST
From:	tja105@rsphy1.anu.edu.au (Timothy Allen)
To:	moo-cows.parc@xerox.com
Subject: exits

I sent this out a day or so ago, but I never got it back and it doesn't
sound like Lambda got it either, so I'm reposting it. Lambda's recent
posting points out one or two more good points his system has that I
haven't mentioned here, such as built-in look for exits that would
enable transparent exits quite easily.





Well, there still doesn't seem to be much of a consensus about exits, so
I shall have a go at summarizing the story so far (as I see it :) ) in
order to (hopefully) facilitate some sort of agreement.

There are three exit schemes on the market.

A) The system from AlphaMOO. Exits are objects, they sit in the room
they lead from and have a dest prop pointing to somewhere else. The
huh verb on the room matches verbs with the names of objects in the
room and calls the invoke verb on the object it matches.

B) Exits are described by properties on the room. The huh verb checks
through a list of exits it has and when it finds a match it looks up
where that exit is supposed to go and tries to move the player there,
giving the usual messages etc on the way.

C) Lambda's system. Exits are objects, they sit at #-1. The huh verb on
the room looks through a list of exits it has and tries to match with
the name/alias/handle of one of the exit objects in its list. When it
matches, it calls invoke on that object.

I'll now have a go at summarizing what I think the pros and cons of the
various schemes are.

1) Robustness
We want to make it as unlikely as possible that the db will become
inconsistent.

In system A, this is safeguarded by the fact that it depends almost
solely upon the hard-coded contents and location properties. The
hard-coding at the moment prevents inconsistencies from arising between
the contents and location props. This may change if Lambda takes
contents and location out of the server.

In B, the exits are maintained on properties of the room. Because the
information is only stored in one place, there is no possibility for
inconsistency.

In C, the exits are maintained by two different systems that can come
into conflict. Because the exits are objects, they are maintained by the
usual mechanisms of the server for objects. ie, they can be recycled,
moved around, etc. Exits are also maintained on a list on the room.
Because this list is not a hard-coded property, it does not cooperate
with the server. In particular, if an exit is recycled, the room is not
informed of this fact and its exit list will be wrong. This sort of
problem can easily arise with novice builders (also with builders who
don't consider themselves novices...:( ).

One problem shared by all three systems is the possibilty of an exit
pointing to somewhere that doesn't exist. If a room gets recycled, the
exits pointing to it should be informed, though it'd be a pain to
implement this.

In summary, A is acceptable but will have problems if movement gets
taken out of the server. However, there will be far worse problems if
this happens. B has no problems at all in this regard. C has great
potential for problems.


2) Flexibility
We would like it to be possible to instantiate sub-classes of exit, eg
transparent exits, exits with locking, exits with random
destinations...

In A, this is easy, you just make a sub-class of the exit and drop it
in the room.

In B, this can be done, but is less flexible. You have to instantiate a
sub-class of the room. If you want all the exits in the room to work a
particular way, this is OK, but if you want some to behave differently
it'd be a pain.

In C, for some applications you could just make a sub-class of the exit
object, but for most you'd have to hack the room as well. eg, for
transparent exits, you'd have to change the look verb on the room. So
you'd have to make a sub-class of exit _and_ a sub-class of room.

In summary, A is the best, B and C are OK most of the time.


3) Display characteristics.
We want flexibility in the way the room shows players the contents and
exits. The likely ways people would want to do this are (i) a pure list
of contents, including exits, (ii) a list of contents followed by a list
of exits, (iii) a list of contents and no mention of exits (relying on
the room's desc to describe them adequately) and, possibly, (iv) a list
of exits but no contents (or neither). This should probably be under
the control of the owner of the room, but there may be exceptions. It
may be that you could want some exits to appear as ordinary objects in
the room as well as/instead of in the exits list.

In A, (i) is trivial to implement, but this isn't really a selling
point. All the others can be done quite easily too, by modifying the
look verb on the room. You'd need some flag on the exits to tell the
room which objects are exits.

B and C are essentially identical in this respect. Displaying exits
separately is probably slightly more cpu efficient in these cases than
in A.

Summary, all three systems can do about anything you'd want to do with
displaying, but A would be slightly more messy for most things.


4) Building permission
There has to be some notion of who is allowed to build what, where. The
three systems have different implementations of this. An ugly type A
exit can always be built, using a 'go' verb or similar.

In A, anyone can build an exit from a room, they just drop it there. The
owner of the destination room decides, via an accept verb, whether
people using that exit can go there, and the owner of the room the exit
is in can put filters in the huh verb to allow an exit to function
naturally or not if desired. If the owner takes a dislike to an exit,
.ps (I'm humouring Gary here :)) can simply eject it, and/or filter it out
in the huh verb.

In B, the owner of the room can decide whether building of exits by
other people is permitted, and can allow or disallow it at any time.
The exit information belongs to the owner of the room, but the
modification verbs are written to allow the original builder of the
exit to modify the exit, as well as the owner. The owner of destination
rooms still has the right to refuse entry, of course. The room owner
can remove any exits .ps doesn't like, and could filter them out if .ps
wanted to disable them without destroying the builder's (im)mortal
prose, though it'd be hard for the builder to move it somewhere else.

In C, at the moment anyone can build an exit, but I gather Lambda has
plans to change that. The exit object belongs to the builder, so the
builder can change the properties (messages, dest etc) of the exit. The
owner of the room can remove an exit from the exit list property of the
room to disable it.

Summary: A is more flexible and more messy, B is less messy, and C is
somewhere in-between.


Over-all summary: A is the most flexible, B the most robust and
conceptually simple. C is at best second-best in all categories, often
third-best. It suffers from being a kludge between A and B.

Acknowledgement: The author acknowledges conversations with Gary_Severn.
:)

I hope this helps sort things out.
						Tim/Gemba


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <csc2.anu.edu.AU!tja105>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5713>; Mon, 12 Nov 1990 18:53:01 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <17199>; Mon, 12 Nov 1990 18:52:11 PST
Received: from csc2.anu.oz.au ([130.56.4.25]) by alpha.xerox.com with SMTP id <17193>; Mon, 12 Nov 1990 18:51:00 PST
Received: by csc2.anu.oz.au (4.0/1.0)
	id AA04276; Tue, 13 Nov 90 13:50:34 EST
X-NS-Transport-ID: 08002008D0FD00042ED9
Message-ID: <9011130250.AA04276@csc2.anu.oz.au>
Date:	Tue, 13 Nov 1990 10:50:34 PST
From:	tja105@csc2.anu.edu.AU ("Timothy J Allen")
To:	moo-cows.parc@xerox.com
Subject: Spoofing

Lambda has asked for details about why anti-spoofing doesn't work. I've
created a spoofer to demonstrate the problem and left it in the entrance
hall, but I'll explain the point here.

At the moment, if you have your paranoid flag set, everything you hear
gets prefixed with player.name (player), unless player==you. This
assumes that any spoofing attempts would be triggered by someone else.
However, this assumption is wrong, it's quite easy to spoof using a tell
verb. Then you can be spoofed by just talking or posing or even just
arriving.

A really nasty spoofer would probably use forking to delay the spoofing
response to make it harder to detect what it was triggered by.

I pointed this problem out to Ghond on AlphaMOO, and suggested using
caller.owner.name instead of player.name as a prefix. That stopped this
particular spoofer from working, but anti-spoofing then didn't work for
anything else. Ghond suggested you could have both player and caller.owner
as prefixes, but that'd be a bit cumbersome.

The reason I suggested that having a caller list would help is that I'm sure
some tight algorithm can be found involving looking through the caller
list. Unfortunately, I haven't devised one yet, so I don't have any firm
grounds for this assertion.

					Tim/Gemba


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <anu.anu.oz.au!guest>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5713>; Mon, 12 Nov 1990 21:21:50 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <17207>; Mon, 12 Nov 1990 21:20:16 PST
Received: from anu.anu.oz.au ([130.56.4.1]) by alpha.xerox.com with SMTP id <17205>; Mon, 12 Nov 1990 21:18:53 PST
Received: by anu.anu.oz.au (5.57/1.0)
	id AA27258; Tue, 13 Nov 90 16:15:04 EST
Posted-Date: Tue, 13 Nov 90 16:15:04 EST
X-NS-Transport-ID: 08002008D0FD00042FEA
Message-ID: <9011130515.AA27258@anu.anu.oz.au>
Date:	Tue, 13 Nov 1990 13:15:04 PST
From:	dxb105@phys.anu.oz.au (David Bofinger)
Sender: guest@anu.anu.oz.au
To:	mc@anu.anu.oz.au
Subject: The Trojans strike back

>All this discussion is great fun, but it sure does take a lot of time to
>read all of that mail... :-)

Amen.

>My intent was (eventually!) to make [.location and .contents]
>normal properties that are owned by the wizard and not writable and not
>'children-inherit-ownership' (or whatever the 'c' permissions bit stands
>for...).

OK, that would work, I guess. Though if normal programmers can't use them
directly it's not going to be much different from now.

>My answer to [the undroppable object problem]
>is to say, ``Perhaps you need a better, more
>picky :accept verb...''.

I don't want to stop people giving things to me. I'd much rather just be able
to drop them. Surely that's a more convenient convention (excuse the
alliteration).

>  I was thinking, for example, that I wouldn't
>mind having an :accept verb on me that refused unless player == me. 

OK, so I write something into the :tell verb on Gemba's spoofer that gives you
something obnoxious. Checking player isn't a wonderful test, all it really
tells you is that player seems to be somewhere in the vicinity.

>On the same subject, Gemba says that the cursed-sword motivation doesn't
>hold up, but I couldn't follow his reasoning.

I _think_ that Gemba's thesis is that RPG systems have to maintain so much on
an auxilliary database anyway that it's easy to add in cursedness (don't let
them wield other weapons if they picked up one that was cursed). My objection
to Lambda's cursed sword implementation is that it doesn't depend on any sort
of owner privilege -- I can give you a cursed sword while you're standing in
the living room, and you still can't get rid of it.

>  My fix [for ejection purposes], like something Gemba
>suggested but less radical, is for a wizard to write a verb on all rooms
>(or perhaps players) that allows the owner of a room to eject items

Mine was rather more radical -- make this the standard method of moving people
about. If rooms have the power to eject, you could write an exit that always
ejected people to somewhere with no name and no desc, then another room uses
their moveto() to suck them in .... no, that's getting a bit _too_ wierd.

>(into the Garage?  That could be fun...).

Certainly the place for it, as the house stands.



>[...] a permissions bit on verbs letting them
>execute with the permissions of the child object who inherited the verb,
>is also a big problem.  Consider the idea dropped.  It's always a shame
>when things that could be used for good purposes must be scrapped in
>order to protect against nasty people.  Sigh.

I thought maybe you could get around this if you prohibited creating an object
that belongs to another person, but maybe you're right. I don't like the idea
of people creating objects that belong to me, anyway, I would like to feel I
was responsible for the objects I owned.

>[inconsistencies in exit databases are] a
>problem whenever you put a reference to some object in some other
>object, something we do all of the time.

Well, yes, to some extent. But if you can write it without permitting that sort
of thing, why not?

>-- Stop reusing the object numbers of recycled objects.

Not really recyucling anymore, then. :)

> [I haven't yet looked at what's involved in backing out this feature,
>but it can't be very hard.]

No? That would pleasantly surprise me. Well, if you don't mind, go for it. But
it should be possible for a wizard to create an object with any recycled
number, in case object #216 gets recycled, and _everything_ refers to it.

>My biggest problem with Gemba's representation, though, is that it makes
>subclassing exits a real pain.

I agree. For conventional TinyMud-style programming, they're great. My wumpus
caves on alpha were a simplified Gemba system.

>Gary still likes the old, AlphaMOO style of representation.

Again, true.

>  I don't
>think that we've given anything up here over that style and we've
>instead gained some programming convenience.

Programming convenience? We have to maintain two lists, instead of one, and
horrifying inconsistencies have become conceivable (though it sounds like only
wizards will be able to create them). I don't like to sound negative, but my
feeling about the \Lambda\gamma exit system is "ours but to wonder _why_???".

> The 'look' and 'describe' verbs use a
>common mechanism that includes the .exits list in the search for matches.

Oh. So the look and describe verbs think exits are in the room, but nothing
else does. I'll have to think about whether I like that convention....

>On the subject of adding exits from a room you don't own, I suggested
>that you don't do so; instead, you get the owner of the room to add it
>for you.

It certainly should be possible to have unrestricted building rooms, but this
is easy in any of the systems. Have you read Gemba's review article on exits?

>I create the exit in limbo, fix up all of the
>messages and then get you to put it on your room's .exits list.

That's exactly what happens in the G7 version of alpha anyway. The differences
are that (1) Only foreign exits need to be put on the list, and (2) If you
aren't on the list in Lambda's system the room thinks you're an object, whereas
if you aren't on the list in my system the room thinks you're an unauthorised
exit, and sends you to coventry (I haven't decided whether that should be
metaphorical or literal yet :), I suppose it should be a flag on the room). Of
course, if the room is unrestricted, there's no need for a foreign exits list.

>Finally, Gemba once again brings up what appears to be one of Gary's
>favorite causes: making 'caller' a list to allow ``anti-spoofing''. 
>Could one of you PLEASE write down in detail just what you're worried
>about here, just why the current .paranoid flag isn't sufficient, and
>just how a 'caller' list would help?  In detail.  Please?

What we are worried about: the spoofer in the entrance hall is a primitive
version of it. The production model would have a front end to make it lie in
wait for specific targets, and would use delayed forking so the spoofs wouldn't
look suspicious.

Why .paranoid doesn't work. All .paranoid tells you is who the message was
originally triggered by. But most non-trivial, and all social, activities (say,
emote (aside: why is it called emote? pose is better), exits, etc.) induce a
good supply of broadcast tells. The spoofer uses those calls as a trojan horse
entry point.

How the caller list would help. A caller list is a list of the objects that the
verb has been called through. Not, please note, a list of those verbs. For
instance, if I do a conventional say, then:

player types say
  room:say calls emote1,
    room:emote1 calls announce
      room:announce calls listener:tell
	listener:tell looks at the callers list, and sees: {player, room}. That
		sounds legit to it, so it passes the string to the default
		player's tell.

If Gemba's spoofer is in the vicinity, this happens instead.

player types say
  room:say calls emote1,
    room:emote1 calls announce
      room:announce calls listener:tell
	listener:tell looks at the callers list, and sees: {player, room}. That
		sounds legit to it, so it passes the string to the default
		player's tell. All the same so far.
      room:announce calls spoofer:tell
	spoofer:tell calls innocent_third_party tell with 'player says "i_3_p
		is a quiche-eater".'.
	  i_3_p:tell looks at the caller list, and sees: {player, room,
		spoofer, room}. It gets suspiciuous (the list doesn't consist
		of a player and then this.location), and prepends that list to
		the spoofed message. We can only hope that i_3_p is more
		suspicious than confused...

Of course, this system will probably trigger on a lot of exits, where caller
will be {player, room, exit, room}. All such a paranoid filter says is "this
message was not directly expressed by the player mentioned, and may not
represent .pp true opinions.", which is true of exits, when you think about it.
(To pick a rather innoccuous possibility, "Who said I crawled on my hands and
knees into the grotto chamber! I would have used my geological pick on the
entrance first! Spoofing!" :} ). You could think of much nastier examples.
Of course, most players won't walk around with their paranoid bits set, most of
the time. Perhaps the paranoid filter should prepend a single character,
denoting (1) consistent with say/emote (2) consistent with normal exit (3)
consistent with neither of the above. Then another setting on the flag would
give gory details, if needed. Of course, spoofers are like terrorists, you
can't really stop them but you can hope to bring them to justice. After, of
course, the victim has been gunned down.

Lambda (unless it was spoofed :)) said once that callers[2] wouldn't work for a
permission handling system because moveto() might call several verbs before
getting to accept. That's one of the reasons I believe callers should just keep
a list of the objects, with no adjacent duplications. It wouldn't catch every
occurence, but it would most of them. I presume it would be straight-forward to
code?

Anyway, I hope we can settle on a convention acceptable to us all. I don't
really have a project in mind for building, though I'll probably "help" Gemba
on the Bovine Illuminati. I think the Strasbourg clock could be an attraction,
provided enough people get interested, so I'll probably fiddle a bit with that.
------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
		MOO:	Gary_Severn
------------------------------------------------------------------------------
"When a scientific genius becomes involved in the mystical mumbo-jumbo, the
    result is likely to be a lunatic whose quest for eternal life massacres
    everything in sight, but such poor souls wouldn't willingly harm a fly"
					-- Barry Hughart, `Bridge of Birds'


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <watcgl.waterloo.EDU!sfwhite>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5713>; Tue, 13 Nov 1990 14:45:49 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <17257>; Tue, 13 Nov 1990 14:44:32 PST
Received: from watcgl.waterloo.edu ([129.97.128.64]) by alpha.xerox.com with SMTP id <17255>; Tue, 13 Nov 1990 14:42:32 PST
Received: by watcgl.waterloo.edu
	id <AA20429>; Tue, 13 Nov 90 17:38:04 EST
X-NS-Transport-ID: 08002008D0FD000437CA
Message-ID: <9011132238.AA20429@watcgl.waterloo.edu>
Date:	Tue, 13 Nov 1990 14:38:04 PST
From:	Stephen White <sfwhite@watcgl.waterloo.EDU>
To:	MOO-Cows.parc@xerox.com, tja105@csc2.anu.edu.AU
Subject: Re:  Exits etc

>                                              If any programmer can write
> a simple program that will make the db inconsistent, there is plenty of
> scope for severe problems.

i would amend this to 'if any programmer can write a simple program that
will make the db inconsistent, there's something wrong with the db.

i envisioned implementing .location and .contents (and presumably
.location and .exits) as they are implemented in the server now:
read-only by everyone; only writeable by the programs which implement
"move()" or "moveto()" or whatever.  wizards will have to be cautious.

>                                                                 Maybe
> the exits should be on properties of the room, rather than separate
> objects.

that was what i envisioned.

> the present system is that if you recycle an exit, it doesn't disappear
> from the exits list.

hmmm.  perhaps the system @recycle or .destroy command or whatever should
call a foo:recycle() function to ask it to clean up any stuff it needs to.

stephen


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <watcgl.waterloo.EDU!sfwhite>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5713>; Tue, 13 Nov 1990 15:33:34 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <17245>; Tue, 13 Nov 1990 15:32:25 PST
Received: from watcgl.waterloo.edu ([129.97.128.64]) by alpha.xerox.com with SMTP id <17255>; Tue, 13 Nov 1990 15:31:21 PST
Received: by watcgl.waterloo.edu
	id <AA22046>; Tue, 13 Nov 90 18:30:49 EST
X-NS-Transport-ID: 08002008D0FD0004388E
Message-ID: <9011132330.AA22046@watcgl.waterloo.edu>
Date:	Tue, 13 Nov 1990 15:30:49 PST
From:	Stephen White <sfwhite@watcgl.waterloo.EDU>
To:	moo-cows.parc@xerox.com, tja105@rsphy1.anu.edu.AU
Subject: Re:  exits

hmmm. one consideration you guys haven't mentioned is that the
alphaMOO system (using objects with 'invoke' verbs) can't handle
two exits with the same handles.

so, for example, if you have an exit called 'a door heading south',
and an object entitled 'a window facing south', the parser won't
know what to do with 'south'.

this is one reason i removed the 'invoke' verb.

the other reason is that, in tiny* building, an easy, non-programming
method of having random chance is to use two identically-named exits.
you can also use two same-name exits locked to different things to
enable different destinations.

to allow non-programmers to use these features, i thought the 'huh on
room' method would be more flexible (ie., they can be simulated
more easily).

presumably, gemba's system could also handle this.

for the record, i am in favour of .exits lists, and exit objects, for
mostly for the convenience of sub-class creation.

the only valid reason i can see not to use them is that the .exits
field isn't updated on recycling.  however, implementing a 'recycle'
call (as i mentioned in the previous message) would solve this.

stephen


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com!pavel>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5714>; Tue, 13 Nov 1990 16:16:00 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <17226>; Tue, 13 Nov 1990 16:14:52 PST
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <17276>; Tue, 13 Nov 1990 16:12:27 PST
Received: by lambda.parc.xerox.com
	(5.61+/IDA-1.2.8/gandalf) id AA06476; Tue, 13 Nov 90 16:09:48 PST
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.lambda.parc.xerox.com.sun4.40
          via MS.5.6.lambda.parc.xerox.com.sun4_40;
          Tue, 13 Nov 1990 16:09:46 -0800 (PST)
X-NS-Transport-ID: 08002008D0FD00043919
In-Reply-to: <9011132331.AA06106@rsphy1.anu.edu.au>
Message-ID: <YbE8h_oB0KJL8NC10H@lambda.parc.xerox.com>
References: <9011132331.AA06106@rsphy1.anu.edu.au>
Date:	Tue, 13 Nov 1990 16:09:46 PST
From:	Pavel Curtis <pavel@parc.xerox.COM>
To:	moo-cows.parc@xerox.com
Subject: Re: exits

> 2) Flexibility
> We would like it to be possible to instantiate sub-classes of exit, eg
> transparent exits, exits with locking, exits with random
> destinations...

> In C, for some applications you could just make a sub-class of the exit
> object, but for most you'd have to hack the room as well. eg, for
> transparent exits, you'd have to change the look verb on the room. So
> you'd have to make a sub-class of exit _and_ a sub-class of room.

This is wrong, isn't it?  Doesn't one merely need to create a subclass
of exit whose look_self verb calls that of the destination?

> 4) Building permission
> There has to be some notion of who is allowed to build what, where. The
> three systems have different implementations of this. An ugly type A
> exit can always be built, using a 'go' verb or similar.

> In C, at the moment anyone can build an exit, but I gather Lambda has
> plans to change that. The exit object belongs to the builder, so the
> builder can change the properties (messages, dest etc) of the exit. The
> owner of the room can remove an exit from the exit list property of the
> room to disable it.

> Summary: A is more flexible and more messy, B is less messy, and C is
> somewhere in-between.

I guess that I don't see where C is any messier than B here.  Are you
referring to the fact that, in C, the owner of the room can't change the
properties of the exit?  I'm not entirely sure that I consider that a
mess...

> Over-all summary: A is the most flexible, B the most robust and
> conceptually simple. C is at best second-best in all categories, often
> third-best. It suffers from being a kludge between A and B.

I don't see this summary at all.  While C is undeniably less robust with
regard to the current recycling facility, it is on top for flexibility
and display characteristics and arguably the least messy solution to the
building permission problem.  In any case, it doesn't seem to be a
kludge, between A and B or otherwise.

	Pavel/Lambda


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com!pavel>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5714>; Tue, 13 Nov 1990 16:32:13 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <17248>; Tue, 13 Nov 1990 16:30:53 PST
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <17254>; Tue, 13 Nov 1990 16:29:27 PST
Received: by lambda.parc.xerox.com
	(5.61+/IDA-1.2.8/gandalf) id AA06484; Tue, 13 Nov 90 16:28:55 PST
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.lambda.parc.xerox.com.sun4.40
          via MS.5.6.lambda.parc.xerox.com.sun4_40;
          Tue, 13 Nov 1990 16:28:54 -0800 (PST)
X-NS-Transport-ID: 08002008D0FD0004394D
In-Reply-to: <9011130515.AA27258@anu.anu.oz.au>
Message-ID: <8bE8z6MB0KJLENC21V@lambda.parc.xerox.com>
References: <9011130515.AA27258@anu.anu.oz.au>
Date:	Tue, 13 Nov 1990 16:28:54 PST
From:	Pavel Curtis <pavel@parc.xerox.com>
To:	moo-cows.parc@xerox.com
Subject: Re: The Trojans strike back

> >My answer to [the undroppable object problem]
> >is to say, ``Perhaps you need a better, more
> >picky :accept verb...''.

> I don't want to stop people giving things to me. I'd much rather just be able
> to drop them. Surely that's a more convenient convention...

I don't think you can have it both ways.  If you're afraid of people
giving you nasty things, don't accept them.  Perhaps you could come up
with a mechanism that allows giving in a convenient way but doesn't
allow people to force things on you.

> >  I was thinking, for example, that I wouldn't
> >mind having an :accept verb on me that refused unless player == me. 

> OK, so I write something into the :tell verb on Gemba's spoofer that
> gives you something obnoxious. Checking player isn't a wonderful test,
> all it really
> tells you is that player seems to be somewhere in the vicinity.

The answer to this kind of nonsense is to kick out the creater of the
spoofer.  There are limits to how much I'm willing to constrain
programmers of neat and interesting puzzles just to protect us against
miscreants.

	Pavel


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com!pavel>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5714>; Tue, 13 Nov 1990 17:12:45 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <17248>; Tue, 13 Nov 1990 17:10:45 PST
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <17249>; Tue, 13 Nov 1990 16:21:42 PST
Received: by lambda.parc.xerox.com
	(5.61+/IDA-1.2.8/gandalf) id AA06479; Tue, 13 Nov 90 16:20:41 PST
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.lambda.parc.xerox.com.sun4.40
          via MS.5.6.lambda.parc.xerox.com.sun4_40;
          Tue, 13 Nov 1990 16:20:40 -0800 (PST)
X-NS-Transport-ID: 08002008D0FD00043933
In-Reply-to: <9011130250.AA04276@csc2.anu.oz.au>
Message-ID: <cbE8rMAB0KJLQNC1Ra@lambda.parc.xerox.com>
References: <9011130250.AA04276@csc2.anu.oz.au>
Date:	Tue, 13 Nov 1990 16:20:40 PST
From:	Pavel Curtis <pavel@PARC.Xerox.COM>
To:	MOO-Cows.parc@xerox.com
Subject: Re: Spoofing

I have now played with Gemba's Spoofer in the entrance hall and, having
tired of it, put it in Haakon's pocket so that it won't be an annoyance.
 Feel free to recycle it, Gemba.

Thanks to Gemba and Gary, I now understand what they intend to use the
'callers' list for.  I will put it on my ToDo list, but it goes at the
bottom, since I don't think that the kinds of spoofing that it can (try
to) protect against is all that serious in the first place and because
I'd rather work on stuff that has a more immediate payback in LambdaMOO.
 Just for my future information, do y'all agree with Gary's intent that
the list have all adjacent duplicates squeezed down to one?

	Pavel

PS- The create() function has now been fixed so that the second (owner)
argument is optional, defaulting to the programmer of the calling verb. 
The owner argument can only be different from this if the programmer is
a wizard.


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com!pavel>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5716>; Tue, 13 Nov 1990 17:13:47 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <17265>; Tue, 13 Nov 1990 17:12:23 PST
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <17257>; Tue, 13 Nov 1990 16:40:49 PST
Received: by lambda.parc.xerox.com
	(5.61+/IDA-1.2.8/gandalf) id AA06498; Tue, 13 Nov 90 16:39:20 PST
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.lambda.parc.xerox.com.sun4.40
          via MS.5.6.lambda.parc.xerox.com.sun4_40;
          Tue, 13 Nov 1990 16:39:19 -0800 (PST)
X-NS-Transport-ID: 08002008D0FD00043978
In-Reply-to: <9011132238.AA20429@watcgl.waterloo.edu>
Message-ID: <QbE98r0B0KJL0NC2wq@lambda.parc.xerox.com>
References: <9011132238.AA20429@watcgl.waterloo.edu>
Date:	Tue, 13 Nov 1990 16:39:19 PST
From:	Pavel Curtis <pavel@parc.xerox.COM>
To:	MOO-Cows.parc@xerox.com
Subject: Re: Exits etc

> >                                              If any programmer can write
> > a simple program that will make the db inconsistent, there is plenty of
> > scope for severe problems.

> i would amend this to 'if any programmer can write a simple program that
> will make the db inconsistent, there's something wrong with the db.

If by inconsistent you simply mean that there's a pointer somewhere to a
recycled object, then it will always be trivial for any programmer to
make the DB inconsistent, right?  Even with your :recycle idea, one
could simply `forget' to write such a verb for your new class of objects.

No, I think that the best we can probably do is to go ahead with Ghond's
:recycle idea so that it's easy for people to be winners and also add
some code to the DB checkpointer that detects any references to recycled
objects and prints out (in the log) enough information to allow the
local wizard to fix things up again.  I just can't see any better way
around this problem, short of trying to get some kind of
reference-counting/garbage-collection system installed in the server. 
Frankly, I have my doubts about how easily or robustly it could be done.

Sigh.

	Pavel


