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