2008/5/18 Lee Begg <[EMAIL PROTECTED]>: > Stopping the server can be done with signals. I guess an /etc/init.d/ script > should be written sometime.
This is planned as part of daemonizing the server. > I guess my take on this is: > > - maybe an ultra minimum client with tpserver-cpp (subproject similar in > autoconf setup to libltdl) > - Fully featured client separate > - Small client embedded in game clients. > > An ultra minimum client might have no autocompletion, and basically acts as a > (very) dumb string in -> string out pipe. I'm not sure about this. Now that we're talking about having autocompletion and using command IDs (i.e., having a local list at the client), a dumb string pipe like that would just shift the code required to do all that onto the server side. Anyway, if we put the main CLI client in as a subproject, people who know they won't need it on the same machine can configure the build to exclude it. I can't see the "full" CLI client source being very big by itself, it's just its dependencies (probably libtpproto-cpp with admin protocol additions and maybe libtprl?) we'd be worrying about, and those won't get pulled in if the client is excluded. > Why not use ids? Easier to decode, check, etc. Now that I've been convinced about local checking and autocompletion this is naturally the case. It will work very similarly to order descriptions. My wiki page is being updated to reflect. > Why not use parameters (like string, int, range, etc) instead of just argument > strings? Yes, the command description would include this sort of information similarly to order descriptions. > Command result sounds better than okay/fail. It needs to feedback a lot of > text in some cases. I was debating whether to just use log messages for the text (along with the Okay/Fail), but what makes me lean towards Command Result personally is that that way we can provide an admin client with richer (machine-readable) feedback than simply Okay or Fail. I can't think of what that's useful for now, but there's no reason not to have it really. > I wouldn't expect the list of commands to change much. Since log messages are > already asynchronous, it makes sense that new commands could/should be sent > asynchronously to the admin client to tell of the change. I mentioned having the server push command set updates to the admin client(s) briefly on IRC, but is there any analogous mechanism for that in order descriptions (or any part of the protocol, for that matter)? The conservative compromise I'm envisioning is to put a flag in the Command Result frame informing the client to pull the updates, so usually this would be set in the result of a command that would result in new commands becoming available, such as loading a ruleset. A better solution might be a new frame type, asynchronous like the log message, that simply notifies the client to pull the set. -- Aaron Mavrinac www.mavrinac.com PGP Public Key: http://www.mavrinac.com/pgp.asc _______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
