Subject: $room:announce*_all_but

From: [email-masked] (Glusman Gustavo)
Date: Wed, 4 Aug 1993 06:43:34 -0700

I noticed two things about the room's :announce*_all_but:
1-Why are there three verbs? Why not like there is #1:announce*_all_but,
handling all three possibilities?
2-All three :announces loop telling all objects in the room the message.
What if (as happened already) some object's :tell fails? (in this case, 
fails can be: stops running with a traceback, or takes too much time to end)

Is there anything wrong with the following possibility?
@verb $room:announce*_all_but tnt rdx
@prog $room:announce
dudes=this.contents;
text=args;
if (verb=="announce")
  dudes=setremove(dudes, player);
elseif (verb=="announce_all_but")
  text = listdelete(text, 1);
  for l in (args[1])
    dudes = setremove(dudes, l);
  endfor
endif
for dude in (dudes)
  fork (0)
    dude:tell(@text);
  endfork
endfor
.

Thus, we have only one verb handling it all, and it forks - let the :tell
break down now...

Gustavo@Janus,JHM,TTM,etc (.Gustavo@Lambda)

---

From: [email-masked] (Jonathan Bradshaw)
Date: Wed, 4 Aug 1993 06:20:09 -0700

> Gustavo@Janus,JHM,TTM,etc (.Gustavo@Lambda)

Would that cause the possibility of spam? Where due to some :tell verbs
taking time, a number of announce verbs are placed in the Que slowing
the system down?

-- 
 Jonathan Bradshaw | Preferred E-Mail is [email-masked] | Ham N9OXE
 WNDU-AM/FM/TV South Bend, IN | Disclaimer "My opinions are not my employers"
 "If any girl rejects you, don't you doubt it's part of the .plan"- D. Gibson

---

From: Judy Anderson <[email-masked]>
Date: Wed, 4 Aug 1993 10:01:19 -0700

Pavel probably will disagree with me, but indeed Jonathan is right:
forking inside every announce would drag things down into a horrible
morass of spammage.  Heck, we lose with just a *few* people forking
during their :tells; if *everything* forked it would be a disaster.
Well, on LMOO anyway.  Smaller moos would be able to cope.

Also, if you forked for every tell, things would end up potentially in
different orders for different people, depending on whose task queue
was used to put which forks in and suchlike.  I kind of like it that I
can pretty much count on someone else's screen looking the same as
mine.

The answer is: if someone's :tell is broken, then :announce stops on
those people.  It is considered (well by me anyway) to be highly
antisocial to hack on your :tell in a public place.  Sometimes you
just can't bulletproof yourself against every possible failure mode
and still be able to operate the MOO "reasonably" (for some definition
of "reasonable"; LMOO hasn't been reasonable for years :-)

Judy Anderson yclept yduJ   [email-masked]  'yduJ' rhymes with 'fudge'
    [ LambdaMOO is lambda.parc.xerox.com 8888 / 13.2.116.36 8888 ]
       Join the League for Programming Freedom, [email-masked]

---

From: Larry Masinter <[email-masked]>
Date: Wed, 4 Aug 1993 10:19:50 -0700

You can always merge verbs with similar arguments by using the
 if (verb == "case1")

clause.

However, testing for verb  == ... is much less efficient than just
letting the built-in verb discrimination decide which verb you're
really in.

In general, it's a good idea to avoid merging verbs unless the verbs
are very large (these aren't), are infrequently called (these are some
of the most frequently called verbs in the MOO, I think), and the
amount of difference between the verbs you're calling is small (well,
that's true here).

I'll also go along with the comment that using fork(0) to protect from
errors also can cause some very serious lag storms.