From Thousand Parsec Wiki
Revision as of 08:36, 2 May 2008 by Lee Begg (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

TP04 is the fourth version of Thousand Parsec protocol and is currently in active development. The protocol specification is going to be written in XML. Some of the planned features are:

Full XML protocol specification
The protocol will be completely specified in an XML document. This will allow more dynamic languages (such as Python, Ruby and PHP) to read in the protocol document and dynamical create the correct data. This doesn't mean our good documentation is going away (for those people who want to implement it the “hard way”), instead it will be more accurate and contain better linking, lot more useful tables and even an index. The documentation will all be generated using XSLT from the protocol XML document so it will also always be current. The generated protocol document is here.
Meta Protocol definition
A definition on how to talk the “meta protocol”, IE talking to the metaserver and find local games will be specified. It will be almost identical to the current protocol specified separately.
Filter Support
The protocol will support filters such as encryption and compression (or even a 32-bit aligned strings filter), there will be a way to negotiate which filters to use.
Difference Support
The protocol will include (and servers will be required to support) a proper method for downloading “what has changed” lists. This will be extended from the current “get id sequence” stuff but made so it doesn't require downloading every single ID in the universe to find out the differences.
Dynamic Objects
Like how servers can define new a interesting order types, with TP04 servers will also be able to do the same for objects. A wide variety of object properties types will exist, from Graph like properties to just plain strings. This will rapidly allow many more advanced rulesets to exist.
Old Data support
As a side effect of Dynamic Objects, object properties will be able to be “aged”. This means that if you could detect/determine the value in the past, but can’t determine the value now, the client will be able to understand this.
Multiple Instruction queue support
As another side effect of Dynamic Objects, objects will be able to have multiple instruction queues. These will allow for things like “standing battle orders” and “research queues” (and probably plenty of other things I can’t think of at this very moment).
Media support
The current “media support” is just a hack in tpclient-pywx. The dynamic objects will allow proper specification of what media should be used for objects and such.
Research support
The protocol will include support for figuring out which “Research options” are available. It will support a wide range of research methods too (from researching for a specific object, to researching in a general area). Proposal here.
EOT Support
There will be support for things like saying “I’m Done” and “Please end the turn now.”. This will mean we are no longer just stuck with the EOT at a certain time problem like in tpserver-cpp (or when admin runs a special program like in tpserver-py).
Frame Type Versions
Support for changing frames (in a backward compatible way) separately. This will allow better updates of the protocol without having to do a complete new version.


Where to get TP04

The TP04 protocol specification is available in Git repository.

The protocol is available in HTML (incomplete).

Some details which have not made it here yet are at the TP04 protocol page.

Comments and suggestions

If you have a comment about any existing feature or a suggestion about a new feature you can add it here for consideration. You are also encouraged to discuss anything about TP04 on Development Mailing List.

Ruleset information support

Usecase: A user opens the client and opens the list of servers that user can connect to. User sees different servers with different rulesets. Which one is the right one? User would like to see various information about rulesets: name, difficulty level, short description, story behind it, all rules with object descriptions and data...

Suggestion: The protocol should enable sending the above information and the ruleset modules should be required to provide this information to server. Maybe the longer parts (story, rules, objects data) could be provided in the form of an URL pointing to location with the information. Clients could then open these URLs in external browser or using an integrated internal browser.


Personal tools