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. > 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. > 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. > 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. > 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. > 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. > 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. > Any and all advice is appreciated! Thank you. Good plan. 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
