# bf_connect_player(CONN, PLAYER) --> *FTP!!*

Richard Connamacher (phantom@sfsu.edu)
Sun, 4 Aug 1996 02:36:53 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    First to say that I think a connect_player() / bind_connection() builtin
    function would be a good idea and a nice step in making the database more
    independant of specific server nuances.  I do, though, have to disagree
    with both of the reasons posted.  First, HTTP is by definition supposed
    to be _stateless_, which means that logging someone into a MOO through a
    web connection is actually against the HTTP specifications.

    > Sorry, I don't think I was being clear.  It's that "later on" bit that is
    > the problem.  If you _do_ want to log in an FTP connection (and to be
    > honest, I am now not so sure it's a good idea) then :do_login_command()
    > must perform one or more read()s to get the user's reply to the PASS line.
    > But unless :do_login_command() returns *without* suspending (which means
    > without calling read()) then the C function "do_login_task()" ignores the
    > result and does *not* log in the connection.

    You must be confusing the unix ftp client, where it prompts you for a
    password and you type it in, and the actual interface to the FTP server,
    where "PASS" _is_ a command, of the form PASS <password>, which is
    supposed to follow a USER <username> command.  In MOO, if you really
    wanted to make the main interface via FTP, then you'd log someone in
    simply by returning the player's object number after the PASS command
    gets executed.  Running a read() after the USER command gets executed is
    not only unneccessary, but probably also against the FTP protocol specs
    whre PASS is a command and only a command.

    > If you change the read(player) to read(player, 1) (the "non-blocking"
    > option of read(), NOT the default) then you will be logged in.  However,
    > *nothing* else will happen on the MOO until that while loop exits (or runs
    > out of ticks.) So if someone takes a long time to type in "LOG ME IN" (or
    > their password, for instance) the MOO lags like Eeyore on valium.

    Wouldn't it run out of seconds if the user took over four or five seconds
    to respond?  (Yes, I agree that a nonsuspending read loop is a bad idea)

    > ... and this is why I want a "connect_player()" builtin -- so that I can
    > do a while(read(player, 0)) loop, get all the lines I need, return garbage
    > to the server, and call "connect_player()" to log in this connection.

    It's not really totally neccessary, as you can create your own input
    buffer in-database via $do_login_command() and create your own, say,
    $login:read() verb that way.  But, it would be nicer and cleaner if we
    could simply call a builtin function to do the connection binding.

    > I hope that makes more sense now!  :)  As I said, logging in FTP
    > connections may not be such a hot idea, but logging in HTTP connections,
    > that's more desirable.  Plus "connect_player()" would be very useful for
    > linked MOOs and multiprocessor MOOs, as I mentioned before.

    See above note about HTTP statelessness.  A logged in connection to the
    MOO via a java applet that's _served_ over HTTP is perfectly fine, but
    doing the actual perminant logged in connection to the MOO over the HTTP
    isn't, and also isn't really practical.  (You'd have connections logging
    in, then out, then in, then out, constantly.  Remember, HTTP connections
    are very brief and many.)  MOO HTTP servers are great (Believe me, I
    know), but be sure that you do follow the HTTP specifications and
    guidelines, including keeping web connections stateless, nomatter how
    much you might be tempted not to.

    Phantom