On Mon, 19 May 2008, Aaron Mavrinac wrote: > On Sun, May 18, 2008 at 2:45 AM, Tim Ansell <[EMAIL PROTECTED]> wrote: > > In fact, I think 100% of the people who run a tpserver-cpp will need a > > command line tool to control the client (even if only to restart/stop > > the server).
Stopping the server can be done with signals. I guess an /etc/init.d/ script should be written sometime. > > I definitely think that a simple local client needs to ship with the > > server. It should allow all the administration functionality that a > > config file can provide. Once a config file is written, then is not much need for setting things up (cf apache, mysql, etc). > > Being able to configure the server you setup is *required* functionality > > without having to download something else :) Humm.... > No problem. What about the reverse? Maybe we should have a make target > to build only the admin client? 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. > Well, here's my understanding of how OrderDesc works first: client > requests a list of order description IDs, server responds with said > list, client can then request a full description of any of those IDs. > I'm still a bit fuzzy on this. When does the client request a list of > order description IDs? When does it request the actual order > description for a given ID? Normally when the client first connects. Though libtpproto-cpp currently does the request for the actual order description after it has the order but before it decodes it. > My plan so far had been to use the base command strings as identifiers > for commands rather than numeric IDs. Here is the main idea: Why not use ids? Easier to decode, check, etc. > The client sends a Command frame (containing a command string along > with an argument count and argument strings) to be parsed at the > server without any local checking. Why not use parameters (like string, int, range, etc) instead of just argument strings? > The server responds with a Command > Result frame (or maybe just an Okay/Fail frame) if the command was > valid and attempted, a single Command Description frame if the command > was used improperly, or a Fail frame if the command does not exist. If > logging to the admin client, it would also of course send Log Message > frames containing verbose results. The client may request a single > Command Description frame by requesting help on a command, or use a > Get Active Commands frame to get a list of all valid commands (as a > sequence of Command Description frames). Command result sounds better than okay/fail. It needs to feedback a lot of text in some cases. > I have some other ideas involving maintaining a local list or just > atomically verifying each command issued, but these are much more > complicated and don't seem to offer any added benefit. 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. Later Lee
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
