MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: bf_connect_player(CONN, PLAYER) --> *FTP!!*

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
Follow-Ups: References:
Home | Subject Index | Thread Index