Hey,
And one big bullet point was: use the Jabber standards. Ironically. :-) The point of using XML-RPC was not to bypass the "standard XMPP way" of doing things, but to *be* a standard XMPP way of doing things. (Similarly, a lot of the game discovery uses standard service discovery, with a soupcon of XEP-0115.)
Sure I can understand why you might have chosen to go the route you have, for speeds sake, but I still dont like it being done that way, just doesnt feel like the right way to me, and makes it a bit more complex than it need be as far as I can see.
The idea was to make the "game layer" sit cleanly on top of Jabber. That way we could concentrate on making it do what we needed, without requiring Jabber to change each time we came up with a new idea. Proposing Volity as a JEP[*] would have been like building a play-by-email game by requesting an extension to RFC822.
Jabber wouldnt need to change each time, you would just layer it in a similar way to jingle, i.e. the core spec would have all of the base functionality (the stuff common to all games) for stuff like discovery, invitations, joining, creating etc, and then ontop of that you would build additional specs for each game, seems a far cleaner way to me personally, no offense intended, you have done some great work.
Similarly, we thought it would be better for all games to use a "bot" referee, rather than putting game code in the server. Better separation. (And this proved true, because we changed the server software on volity.net a couple of times, with only the smallest hitches to the game system.)
Sure but there are various ways of building the system, the code for processing each game could easily be in separate modules independent from the core without the clients even needing to know, to them it could easily appear that the server/component is the one processing each game (which is how I am building my solution, i.e. separate modules from the core component for each game).
Richard
