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). > > 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. > > Being able to configure the server you setup is *required* functionality > without having to download something else :)
No problem. What about the reverse? Maybe we should have a make target to build only the admin client? >> 2008/4/28 Lee Begg <[EMAIL PROTECTED]>: >> >> > So instead of just having a (more or less) fixed list of commands, have >> >> > the server describe what commands are available. >> >> > >> >> > The actual commands will be hardcoded on the server side, but it can >> >> > export the active list through the protocol. You could even include more >> >> > information. >> >> >> >> Makes sense. Does the TP game protocol do anything similar? (I'm >> >> asking without researching, so a short answer will suffice.) >> > >> > Yes. Order Descriptions, Resource Descriptions, and in TP04 Object >> > Descriptions. > > Have you looked at the above stuff? I'm assuming your doing something > similar to the OrderDesc stuff? 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? 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: 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. 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). 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. > Do you have any xml or similar yet? I have the beginnings of a protocol description here: http://thousandparsec.net/wiki/Tpserver-cpp/Admin I just threw the summary table together, I'll start the actual XML spec file soon. -- 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
