On 21/03/2011 3:19 PM, Christian Anthon wrote: > Please test if older versions of gnubg as well as other programs can > still read the id. This has been my main reason for not making this > kind of changes. Other things you could put in there: >
Already doing so, and it seems okay with extra bits on the end. But my tests aren't complete. reusing existing bits for other reasons is problematic given the checks for validity that older/current software currently do (Like Crawford check when MatchTo = 0 is a failure) and MatchID is reset. > match equity table > match stakes (essentially making the match length a float, could use > the score bits as well, but again portability will be an issue) > Agree. Match Equity Tables is a bit odd in a way. You'd really need to have a unique identifier (An Integer?) for each MET that we know to exist. Using a fullname name to identify a MET seems like a waste. Something I am seriously considering. if we extend the GNUBGID we should at least consider version number bits for the GNUBGID. The Version number would be added as new bits onto the end of the current style ID's. Old software would ignore the extra bits, new software that processes an old ID can assume "version 0". If the extra version bits (3 or 4 would probably suffice for a long time) are added now then we could in theory make future modifications more easily. Change the version means we can assume a different structure for the bits following the new version bits. Comments? -- Michael Petch CApp::Sysware Consulting Ltd. OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304 _______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
