Thanks for the comments! A few responses inline... 2008/4/26 Lee Begg <[EMAIL PROTECTED]>: > Sounds like a good plan. Some notes inline... > > > On Sun, 27 Apr 2008, Aaron Mavrinac wrote: > > Hi, > > > > After poking through the tpserver-cpp console code, I've formulated a > > possible (more specific) plan for tackling the server configuration > > protocol. > > > > First, I would make the interactive console optional, with a command > > line switch to toggle it on or off. I would also make it possible to > > specify what to log to (i.e. syslog, file) on the command line. > > This is already available. > > Any setting can be set on the command line. For example, you can turn on > syslog logging by adding: > > --log_syslog yes > > to the command line, as long as it is not specifically set in a config file.
Ah, the --<key> <value> option. Should have RTFM more carefully. :) > > Next, > > I would add a new protocol alongside the TP protocol, on a different > > port. It would function using much of the same code as the TP > > protocol. It would have its own set of frames, and a separate > > authentication list. Command frames would hook the same functions as > > the commands on the console. > > > > Once the protocol is implemented, I would create a configuration > > client which precisely emulates the local interactive console, > > 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. > > 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? > > This would include the interactive configuration thing with a series > > of questions. Once it is working the internal console would be > > replaced with the stuff from the library (the drawback here is that > > now the internal console is going through the protocol middleman, but > > the alternative -- keeping both implementations -- seems like a > > maintenance nightmare, and this way there is no more tprl in > > tpserver-cpp proper). > > The current internal console would be removed, and the protocol used. > > Humm.... I'm not sure if the new console would need to be a library, it could > be a standalone program. It doesn't actually need to be imbedded into > tpserver-cpp. Admins can use the console/config client instead, and it could > have an option to launch tpserver-cpp. Even better! However, see my Question 1 below... > > Other specialized configuration clients (e.g., > > single-player mode) would use the protocol directly as needed. > > > > Thoughts? Ideas? This is obviously evolving very rapidly right now. :) > > > > For now, my plan is to go through the existing console functionality > > and draft up a configuration protocol specification in the style of > > the TP protocol spec > > (http://thousandparsec.net/tp/dev/documents/protocol3.php). > > Better would be to use the protocol.dtd XML format. Have a look in the > documents repository. protocol3.xml is roughly TP03, and protocol.xml is the > definitive source for TP04. You could create another file, say config.xml or > remoteadmin.xml, and write it in there. There is an xslt in the web > repository (which should be moved to documents sometime) that converts the > xml into the main part of a webpage. The protocol.xml document is turned into > most of http://www.thousandparsec.net/tp/dev/documents/protocolxml.php. A > similar setup could be added for the config protocol. Sounds good, will do. > > 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? > > 2. Any particular preference about the configuration ports? I was > > thinking 6925/6926. > > How about unix socket as well for local access? Not really a lot of > difference > from using localhost (127.0.0.1 or [::1]) though. Yes, we should definitely have a local IPC socket, since in a lot of cases remote access won't be needed at all. > > Any and all advice is appreciated! Thank you. > > Good plan. Thanks. :) > Later > Lee -- 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
