Brendan Lally wrote: > On 10/9/06, Mark Wedel <[EMAIL PROTECTED]> wrote: >> - 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. > > Might I suggest then, that when the 2.0 protocol changes are (vaguey) > finalised, a version of the 1.x server be released which understands a > 2.x version number and acts as though all of the appropriate setup > flags were set (without adding any of the new features), and also is > aware of any new commands that can be sent to it, but merely ignores > them (with suitable draw_info-ed error messages). That way it should > be possible to have a compatibility upgrade to the server allowing > both sets of clients to work for however long it would be until most > distros have upgraded the versions they ship.
It's really hard to say how well that will work until all the changes to the protocol are done. And I don't know right now what all those changes may be. There are several potential issues: - Some existing protocol command is removed from the trunk branch, replaced by something else. In this case, it is easy for the client or server to ignore the command, the problem is that if this command has critical information, doing so results in a broken setup. This scenario probably isn't too likely. - An existing command is extended to include values it did not include before. Depending on the direction of the command, this may or may not be easily handled. For example, if the 2.0 server will send some existing values that the 1.x server won't, that probably won't cause any issues for using a 2.0 client on a 1.x server (it can handle those values, would just never get them). A 1.x client on a 2.0 server will have problems - it will get what it sees as bogus data in some commands. The protocol commands are not self documenting, so the best the client can do is just ignore all data after that bogus value (it won't know the size of the bogus data so won't know how much to skip, etc). And if the change is in the C->S direction, then scenario is reversed - 2.0 client on 1.x server would have issues. I think this scenario is fairly likely to occur. - New values are not added, but rather the meaning or type of existing values are changed (something is currently sent as 16 bits, we decide it should be 32 bits, etc). This basically has all the same issues as the point above. So going back to the original point of the post, which was having a 1.x client that could play on 2.0 servers, this is what I would see have to be done: 1) the 1.x client would have to fully understand the 2.0 protocol. anything less, and there is too great a risk of serious functionality be missing or bugs happening, etc. 2) For this to make sense, this 1.x client would have to be released quite a while before 2.0 is released. releasing it 2 weeks before 2.0 wouldn't make sense - at that point, just grab the 2.0 client, etc 3) Such a client would still have to know/be valid on the protocol version numbers. The client itself could change what SC/CS_VERSION it reports to the server based on what the server tells it (basically lie). It would then choose not to do the setup command based on this. 4) To be compatible with 1.x server, basically all the code related to 1.x protocol commands has to be retained. Now as I type all this in, I see a major problem. If we do the above, it basically removes/obsoletes the 2.0/trunk version of the client. If the 1.x client is fully functional with everything, why do you need a 2.0 client? And it then makes other proposed changes more difficult (getting rid of some of the older client interfaces, doing a cleanup, etc). It would pretty much mean that the 1.x client branch would probably have to be maintained pretty for the duration of the 2.0 release. It's easier to remove old clients or support at the major release than later. In short, if when 2.0 comes out, we say you have to use a 2.0 client, people would not their head and say OK. If instead, when 2.0 comes out, you can use a 2.0 or 1.x client, it becomes very difficult when 2.1 comes out to say you can't use that 1.x client anymore (people will ask what has changed, what can be done, make patches, etc). I don't mind this being unofficially supported (can't control that anyways), but I don't want to support it personally. So what probably makes more sense is this: Release a 2.0 client some time (3 months?) before the projected 2.0 server release, to allow time to make it into the various distributions, etc. Maybe call it a beta release. This 2.0 client could only be used on 2.0 servers (likely missing support for 1.x servers). At the time of the client release, the 2.0 protocol version strings are frozen, and any changes made to the protocol have to go back to using the setup commands. This may have other advantages - I'd expect as we get near, we'd have various public servers running 2.0 code for testing purposes - for that reason, having some clients out there would make sense. The downside is that these 2.0 clients can be used on 1.x servers, but that probably isn't that big an issue. I don't think there should be anything preventing a use from having both 2.x and 1.x clients installed on a system, or if there are things preventing it, it probably just means changing the pathname here or there. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire