On Fri, 2008-05-16 at 20:05 -0400, Aaron Mavrinac wrote: > 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?
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 :) > 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? Do you have any xml or similar yet? Tim 'Mithro' Ansell <snip> _______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
