MOO-cows Mailing List Archive
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.
Subject Index |