> The problem is that if a new OpenPlay client is talking to an old
> OpenPlay server, there's no way to easily construct an enum query
> packet that'll work with both. The new enum query packet must contain
> the client's start time (so that it can determine the roundtrip time
> when the host passes it back in the enum response). The old parsing
> code is very rigid about the query packets it receives. Old hosts will
> reject any enum query that isn't an exact match for the old style.
Without having looked at this myself, is it possible to tack it on to
the end, after any custom data, so the only thing the old OpenPlay
client sees is a different size (or will that kill it too?)
> But (b) will do the trick. By adding a new optional field to the
> Config string, say "enumVersion=2", you can effectively say that your
> client will only send out new-style enum query packets and can only
> receive back query responses from hosts that recognize this version.
> An absence of this field in the config string (which is the case with
> the old OpenPlay code) would imply a version of 1 - the old style enum
> query/response. This should allow all the combinations of new/old
> client/server OpenPlay to work. I'm not super-thrilled about this -
> it's a bit of an arcane way to tell OpenPlay that you want ping times,
> but c'est la vie.
Assuming you are going to have to go with plan B, and use a config
option, it would probably be a good idea to go ahead and add a version
number to the enum packet so we won't have this problem in the future.
If we do that then the config option should probably be something like
"legacyEnum=false" (where legacyEnum=true is default and will give old