On Fri, May 16, 2008 at 3:26 PM, Tim Ansell <[EMAIL PROTECTED]> wrote: >> It actually occurred to me later on that Python lends itself to the >> admin client problem nicely, and since the second target is >> tpclient-pywx, it makes sense to implement the low level stuff in a >> Python module used by both (maybe as part of libtpproto-py?). > > Actually, I think for a basic command line client this is a bad idea > (for a number of reasons): > > * It makes tpserver-cpp dependent on python and having the python > libraries installed. This is the biggest problem I see, shipping > a copy of these libraries will also be a pain. > > * You would want to extend libtpproto2-py (as it uses the xml > files for the protocol description already). libtpproto2-py is > still a long way from being stable. > > I would recommend making a client which is based on a very cut down > version of libtpproto-cpp, or maybe something using one of the code > generators.
It does make more sense to implement the client in C++ as probably most of the time it will live on the same host as the server. However, since part of the project is to make *remote* administration possible, there are cases where the server is required but not the admin client, and vice versa. I tend to think that the admin client should be a separate package for this reason (tpadmin-cpp?), but probably the majority of people installing tpserver-cpp then would also need to install it separately. Thoughts? 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. At any given time, the server will of course know what commands are active. The admin client may find out by issuing something like: Header + Request + Get Active Commands to which the server would respond with something like: Header + Response + Sequence + [Command 1] + [Command 2] ... If we don't need to worry about checking commands locally before sending them to the server, we only really need this for displaying a command list and command help to the user. The possible drawback here is that, since the admin client obviously won't have a hardcoded list of commands synchronized with every server's, it needs to process all commands (except maybe some specific commands that ALL servers must support) in a "dumb" way. The simple solution is having a single frame type for all commands flexible enough to support any kind of command -- which, so far, looks to me like it would be OK. If we do want local checking and various frame types, there are 2 possibilities: 1. We can assume that the admin client's local list is valid as long as a Get Active Commands frame was the last thing issued to the server. This means enforcing that only one admin connection is open at a time, and ensuring that the active command list at the server can only change in response to an admin command. 2. We can never assume the local list is valid. We need some sort of atomic transaction which starts with a Get Active Commands frame, followed by a local check, and finally transmission of the command frame. This would also allow for multiple admin connections. Once I get some feedback on the above I think I'll be ready to write the protocol spec and start coding the server side. Thanks. -- 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
