Re: [Bug-gnubg] Extending MatchID's and software

[Frank Berger]

Hi,

I think using the 6 trailing bits is a very good idea and compatible with 
existing software. When you decide on this issue I'll adapt BGBlitz ASAP.

Reusing other bits is IMHO a bit :) problematic. There might be issue with 
tests, you can't see at a glance it's the new version....

If for some reasons the 6-spare-bits-solution isn't taken, I suggest changing 
the format in a way that one (ore more) additional characters are added. If you 
have an old incompatible SW you simply have to delete the latest character.... 
dead easy to do manually.

ciao
Frank

> Date: Tue, 22 Mar 2011 00:24:18 -0600
> From: Michael Petch <address@hidden>
> Subject: Re: [Bug-gnubg] Extending MatchID's and software
>       compatibility - Good News - 6 bits free
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> 
> Howdy All,
> 
> My original tests assumed a worst case scenario that we would have to
> add extra bytes to the MatchID portion. This might be the case if we
> decided to put a fair bit of extra information in. We have one saving
> grace of course. We are currently not using all the bits available to us.
> 
> A current MatchID is 12 characters base encoded, but only represents
> 66bits of data (A MatchKey currently is 66 bits). 12 characters of base
> 64 encoding can represent a maximum of 72 bits (12 * 6).
> 
> We have 6 bits to spare in our current encoding to do with as we please.
> If we do not exceed a total of 72 bits we seem to remain compatible with
> existing software. 0.14.3, 0.15, 0.90+, Gabbi(online), XG, BgBlitz
> 
> In all cases if I encode 6 extra bits of data to a MatchID and paste it,
> all the software above converts the first 66 bits and ignores the
> remaining 6 bits. In the case of old versions of GNUBG if you paste a
> matchID encoded with an extra 6 bits it will ignore the bits AND will
> update the GUI with a new MatchID computed from only the first 66 bits.
> So you may paste a new MatchID but it will appear as the matchID minus
> the extra 6 bits once updated in the UI. This makes sense since the
> extra 6 bits are meaningless.
> 
> It appears that all software that currently generate the MatchID portion
> of a GNUBGID set the unused 6 bits to zero. If one has no versioning
> information in the bits, one has to take the default zeros into account
> since software that we paste into won't know whether the ID was
> generated from software that added extra bits or not.
> 
> In the case of Jacoby we could add it as bit 67. Since Jacoby wasn't
> encoded previously (but is zero in older ids) and is generally the
> default ON in Money Sessions we would have to reverse the meaning of the
> flag to actually mean "NotJacoby". So if Updated software reads an ID
> generated from older programs and comes across a money session it will
> see the NotJacoby flag (bit 67) as being zero and assumes Jacoby is on.
> If new style software sets bit 67 ON, it will signal Jacoby being off.
> Old software reading new IDs will be none the wiser and just ignore the
> extra data.
> 
> If we ever require more than the 6 bits  and have to extend a MatchID
> beyond 12 base64 encoded characters,  then the software that currently
> exists will have the issues as outline in my previous messages on the
> matter.