Re: More force_input() and $do_command()...

• Date: Sat, 6 Jul 1996 23:50:26 PDT
• From:
  Gustavo Glusman <bmgustav@bioinformatics.weizmann.ac.il>
• Content-Type: text/plain; charset="us-ascii"
• In-Reply-to: <Pine.SOL.3.91.960706220606.29311A-100000@caxy>
• References: <9607062313.AA04370@alfred.ccs.carleton.ca>

Nate wrote:
>Now wait a sec... (and it's time to spark some debate!)
>
>Pavel posted a response to somebody's message about this thread,
>saying that the connection was not made so the text was parsed by
>do_login_command() instead of do_command().  Okay, I guess.  Stupidly,
>I didn't think about this stuff until now, so here's my philosophy
>on the subject.  Basically, I'm trying to decide if this is "right".

A quick test shows that this is a little misunderstanding.
Forcing input on a non-connected positive-number object does *not* call
:do_login_command.
Let's assume #2 is currently connected, and #-12 is an incoming connection:

Objnum       Connection    is_player()        Result of force_input()
------       ----------    -----------        -----------------------
  #2           active         yes                  $do_command
#-12          incoming        no                   $do_login_command
 #-5            none          no                   None
#131            none          no                   None
#133            none          yes                  None

Therefore, it works about as you'd expect. :)
I'd think that forcing input on #133, #131 and #-5, in this example, should
do something else, but I'm not sure what the proper convention should be.
E.g. forcing input on #-5 might raise E_INVARG.

>Another issue... what about multiple listeners?  Should we make an
>extra argument for force_input() to tell what listener object to
>send the command to?  I know that most people currently probably
>are only using #0 for everything with the possible exception of a
>web server (like me), but still, we lose "functionality" if we can
>only force_input() to #0.  Agreements?  Disagreements?

The current server already sends the forced command to the correct listener
object, simply because the command is added to the connection's queue, and
this queue is processed by the listener object. There's no problem and no
inconsistency here.

>If anything comes of this thread and people agree with me, I think
>we should have the next maintainer add a patch for it.  (Pavel, will
>you be announcing the new maintainer soon?  If not, I may ask for
>any bug fixes and make an unofficial one myself if people agree with
>me here.)

I guess you have to re-define the patch, now. And test it. :)
My stand on making unofficial patch releases - it's a free world, but we
all stand to gain if such patches are debated first, and if accepted, added
to the official release.
Naturally, I'm referring to modifications that lead to incompatibilities,
no to extensions.

>(Please don't flame... civilized debate only.)

Hey, have you ever seen anything else on this list? ;)

-------------------------------------------------------------
Gustavo Glusman               Founder/administrator of BioMOO
-- Gustavo@bioinformatics.weizmann.ac.il
-- http://bioinformatics.weizmann.ac.il/Gustavo
-- BioMOO: telnet bioinformatics.weizmann.ac.il 8888
           WWW:   http://bioinfo.weizmann.ac.il/BioMOO

• Re: More force_input() and $do_command()...
• From: Pavel Curtis <pavel@parc.xerox.com>

• Re: force_input() and $do_command()
• From: aq299@freenet.carleton.ca (Jefferson Dubrule)
• More force_input() and $do_command()...
• From: Nate Massey <nmassey@caxy.lfa.lfc.edu>

• Prev: More force_input() and $do_command()...
• Next: Re: More force_input() and $do_command()...
• Index: MOO-cows
• Thread: MOO-cows