On Tue, 20 May 2008, Aaron Mavrinac wrote: > > An ultra minimum client might have no autocompletion, and basically acts > > as a (very) dumb string in -> string out pipe. > > I'm not sure about this. Now that we're talking about having > autocompletion and using command IDs (i.e., having a local list at the > client), a dumb string pipe like that would just shift the code > required to do all that onto the server side. Anyway, if we put the > main CLI client in as a subproject, people who know they won't need it > on the same machine can configure the build to exclude it.
True. It also means that it should be possible to distribute it separately. > I can't see > the "full" CLI client source being very big by itself, it's just its > dependencies (probably libtpproto-cpp with admin protocol additions > and maybe libtprl?) we'd be worrying about, and those won't get pulled > in if the client is excluded. True. Note that libtpproto-cpp is undergoing some changes currently. Also libtpproto-cpp is not currently used by tpserver-cpp. > > Why not use ids? Easier to decode, check, etc. > > Now that I've been convinced about local checking and autocompletion > this is naturally the case. It will work very similarly to order > descriptions. My wiki page is being updated to reflect. Cool. > > Why not use parameters (like string, int, range, etc) instead of just > > argument strings? > > Yes, the command description would include this sort of information > similarly to order descriptions. Cool. > > Command result sounds better than okay/fail. It needs to feedback a lot > > of text in some cases. > > I was debating whether to just use log messages for the text (along > with the Okay/Fail), but what makes me lean towards Command Result > personally is that that way we can provide an admin client with richer > (machine-readable) feedback than simply Okay or Fail. I can't think of > what that's useful for now, but there's no reason not to have it > really. A command Result frame would give a better context for the results. If more "structure" is needed in future, then there wouldn't be too much to change, whereas using okay/fail would require replacing them. > > I wouldn't expect the list of commands to change much. Since log messages > > are already asynchronous, it makes sense that new commands could/should > > be sent asynchronously to the admin client to tell of the change. > > I mentioned having the server push command set updates to the admin > client(s) briefly on IRC, but is there any analogous mechanism for > that in order descriptions (or any part of the protocol, for that > matter)? Not in order descriptions. The server can send asynchronous TimeRemaining frames and probably Component frames. > The conservative compromise I'm envisioning is to put a flag in the > Command Result frame informing the client to pull the updates, so > usually this would be set in the result of a command that would result > in new commands becoming available, such as loading a ruleset. > > A better solution might be a new frame type, asynchronous like the log > message, that simply notifies the client to pull the set. Either are good options. 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
