On Mon, 28 Apr 2008, Aaron Mavrinac wrote: > Thanks for the comments! A few responses inline...
> > I'm not sure if you want to *precisely* emulate the console. There are a > > number of improvements that could be made. > > Fair enough. If anyone with experience has any specific improvements > they'd like to see, let me know, and I will keep them in mind. You could look at using ncurses to have panels in the console, separating the logging from the output. Then again, someone could write a full graphical client (using wx-widgets, qt, gtk, etc, etc). > > > by > > > parsing commands into configuration protocol frames and response > > > frames into interactive output. The actual console for this would be > > > implemented in a separate library, including the command set itself. > > > > I'm thinking that it might not be a bad idea to description-style frames > > for commands, so that different servers/rulesets/users can have different > > commands. > > Can you elaborate here? > > It looks like currently the console command set itself is hard-coded > into console.cpp, but since we wouldn't be calling any tpserver-cpp > functions directly anymore (just sending frames), we can probably pull > it from an XML file or something. That way, ruleset modules could hook > in new custom commands and provide their own accompanying XML file for > the console client. Users could also create XML files for new macros > and such (using existing command frames). Is that kind of what you had > in mind? I would think that tpserver-py would have different commands. New commands will be added in time, and rulesets might add some of their own. Or the commands could change with the state of the server, or who is logged in. So instead of just having a (more or less) fixed list of commands, have the server describe what commands are available. For example: server: I have these commands: set, start game, kill. client: Command "start game" server: I have these commands: set, kill, end turn, add player. 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. > > > Questions: > > > > > > 1. What should the default behaviour be: interactive console or > > > daemon? > > > > I think tpserver-cpp should be a daemon. There needs to be a command > > line switch to stop it for doing so, mainly for debugging. > > Do you mean a switch just to stop it from going to the background? > Since we're removing the embedded console entirely (per your comment > above) and there's already a way to send logging to stdout, what else > is there? Yes. Just need it not to close the terminal file descriptors (stdin, stdout, stderr) and not fork into the background to allow debugging. Also, when it does daemonise, it should stop console logging. > 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
