Comments below. On Tuesday 12 December 2006 03:00, Tim Ansell wrote: > Hello, > > With the release of tpclient-pywx 0.2.0 and all the progress over the > last couple of months I think it's time to start thinking about the next > version of the protocol. > > So what do people think needs to be added/changed to the next version? > Here are some of my thoughts: > > * Better difference support. Currently there are problems with the fact > that you could be running a different server when a person reconnects. > What about objects disappearing? That too doesn't work to well.
Currently, it shouldn't be a problem. I future, I plan that when a fleet is lost in battle, the object id will remain, but the object would be a debris field. That doesn't quite work for everything and objects must eventually disappear from the universe. What is wrong with the object (or generic) id lists with their modtimes? I know that tpserver-cpp doesn't support it on somethings, but they are the sort of thing that doesn't change anyway. > * History support. Currently you can only get the currently active > turn. What happens if you join the game late or miss a turn? Maybe we > should have some way to getting older information. If you join a game late, then you shouldn't see what has happened (except in race/government splits, etc). If you miss a turn, then what good is last turn's information? Moving object positions? Just look at the objects velocity and substract it from the current position. What is the "use case"? What is the value? > * Partial object support. Sometimes you'll only have permission/ability > to only view parts of an object. For example you might only be able to > see certain stats of an object (IE tonnage of a far away fleet). > This would also concern the current problem we have about > designs/components. This is not (necessarily) a protocol issue. Tpserver-cpp supports this in a limited sense, with the order queues for objects, only the owner of the object can see how many objects in the queue. The issue ends up being just how many infomation is needed to be stored on the server side. Does tpserver-cpp have to store a copy of each object for each player sees (ie: o * p objects)? With the dynamic object descriptions below I might vaguely see some reason to protocol level partial objects, maybe. > * Support for dynamic object descriptions. This is kind of like how we > do orders. It would mean we would no longer have to maintain the > separate "Objects" document. > This would also come hand in hand with displaying stats about planets > and economy. I agree with this, as it also solves other problems for me (namely persistence). > * Full protocol XML specification. libtpproto2-py, libtpproto-php and > libtpproto-rb all depend on using the XML document specification. It > would be good if the documentation was generated directly from this XML > specification. > It would also mean that the documentation is easier to maintain (IE > keeping the tables and such up to date sucks.) I understand the value as a nice way to document the protocol, and some of its value for automatically creating implementation in dynamic languages. > * Individual FrameType versioning. I would like to support versioning > the frame types rather then the whole protocol. This would allow > libraries which only partially support for the latest protocol and > better transition between the protocols. WTF!?!?!?? It would make things worst than now. Tpserver-cpp still supports TP02. It takes considerable work to support multiple versions of the protocol, let alone versions for each frame type. What is the "use case"? What is its value? > * Protocol "filter" negotiation. Kind of like what Worldforge's Atlas > uses. IE Using bz2, zlib, 7z for compression, Different encryption and > tunneling methods. Maybe even UDP or other base level transports. Note that Atlas is used to decide between data encodings (from when I last used it, xml or bach; both text based). I vaguely agree with this. It could mean that a server only has to open 3 sockets to fully support clients instead of the current 4 (tp, tps, http, https). The most specific filter I would like to see is tls. Many protocols (I note smtp and http) use STARTTLS as a command to start tls encryption (and jabber has a very round about way of doing the same thing which is similar to what we would need.) > * Support for "technologies" and "research", pretty self explanatory. Yeah. > Can you people think of anything else that you would like? > > Tim In the sf bug tracker I have been adding feature requests (and tagged as such) for our protocol (note these might not need to be in tp04, maybe tp05). So: * Diplomacy * base media url and game statistics * OOG/OOC chat (Out Of Game/ Out Of Character) * Player finished doing turn notification (to server) * new available design/component notification * Object Property (bad name, sorry) setting (ie setting object name, other things that take effect immediately) * Race/player separation? And I'm sure there are many others. In general, I would rather keep going along the lines of TP03 (ie, just extend it) than a full rewrite. We have a lot invested in what already works and I don't really think we want a repeat of the tp01/tp02 transition delay. Do you/we want to completely re-work the protocol or extend our current protocol? Later Lee
pgpusrnlGCOwM.pgp
Description: PGP signature
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
