[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] Re: GNUBG IDs and jacoby/beavers

From: Michael Petch
Subject: Re: [Bug-gnubg] Re: GNUBG IDs and jacoby/beavers
Date: Mon, 21 Mar 2011 17:06:48 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20110303 Thunderbird/3.1.9

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.


Michael Petch
CApp::Sysware Consulting Ltd.
OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304

reply via email to

[Prev in Thread] Current Thread [Next in Thread]