[Top][All Lists]

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

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

From: Frank Berger
Subject: Re: [Bug-gnubg] Extending MatchID's and software
Date: Tue, 22 Mar 2011 18:09:39 +0100


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.


> 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.

reply via email to

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