Please note that everything discussed in this message only pertains to the targetted 2.0 release of crossfire, which is in the trunk. Changes won't be made to the 1.x branch.
It has been noted that within both the client and server, there is a fair amount of old code around to support older versions of the servers and older versions of the client. The setup command has also gotten a lot of options with methods to negotiate what protocol commands it supports, and directly related to that, there is a lot of code in the server that does/does not do something based on what has been negotiated. The idea here is to clean all that up for 2.0. Specifically: - Change the SC_VERSION and CS_VERSION to 2000, to represent 2.0 release. - server and client must have some version to work correctly - mismatched versions may or may not work (client may get data it doesn't understand, server may get client commands it is unable to process) - Version 2.0 compliance means that the client supports the latest implementation of the protocol. Support for superceded protocol commands is removed from both server and client. - Version 2.0 compliance also means that the client supports all the relevant items within the setup command, so that doesn't need to be negotiated (spell info, 64 bit exp values, whatever, so those are not needed in the setup command. Note that there will still be some things done via setup, like faceset, map size, etc - things that are actual preferences, and not protocol selection info. - While 2.0 is in development, any updates/changes to the protocol will result in updating the SC/CS version numbers, and not done via setup. This may mean people need to update their client to play on their test server, but since this is while doing development, I don't think that is unreasonable. - Once 2.0 does release, then any changes to protocol would go back to being enabled via setup commands like done now. - If/when alphas/betas for 2.0 are done, both a client and server release snapshot is done, so no issue with version commands. Pros for doing this: - Helps in code cleanup (get rid of old code) - Enables more rapid code development (easier to make protocol changes, and can remove obsolete code at time new code is added). Note: This doesn't remove the need for discussion on protocol changes - Simplifies protocol, make it clearer what new developers should program to. Cons: - Need 2.0 client to play on 2.0 server (would probably be a requirement at some point anyways) - May not be able to use a 2.0 client to play on an older server (depends on how old, and what protocol commands to use). Could still use the 1.x clients of course. - Developers would need to keep their client and server in sync to play, given requirement of equal protocol versions (may not be that big a deal - I'm not sure how often the protocol will change, and doing svn updates shouldn't be that hard) thoughts? _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire