The request for a public API for backward compatibility checking is in PR 538 <https://github.com/capnproto/capnproto/issues/538>. In light of the discussion here, I propose that a final resolution of that PR would be to expose a public API function that tidily exposes the existing backward-compatibility-check functionality. For example, it would be great to return a compatibility-error-list data structure instead of throwing an unspecified exception.
On Wednesday, October 18, 2017 at 12:45:01 PM UTC-4, Kenton Varda wrote: > > Hi Liam, > > The point is that CompatibilityChecker can catch *some* cases of > incompatibility, but not all -- and it's impossible for it to cover all > cases. So, you could indeed use it as a "safety check", just remember that > there could be false positives (where it reports that the protocols are > compatible, but they actually are not). > > The right way to do this is by loading the schemas into SchemaLoader, and > letting it throw an exception if they aren't compatible. > > -Kenton > > On Tue, Oct 17, 2017 at 5:03 PM, Liam Staskawicz <[email protected] > <javascript:>> wrote: > >> Hi Kenton, >> >> Thanks for the response. I'm interested in identifying scenarios in which >> changes have been made to a schema that break backward compatibility. >> >> Do you think CompatibilityChecker is the wrong approach for that purpose? >> Or just needs to cover more cases before it can be relied upon in that >> context? Something else altogether? >> >> Thanks, >> Liam >> >> >> On Mon, Oct 16, 2017, at 12:09 PM, Kenton Varda wrote: >> >> Hi Liam, >> >> What kind of negotiation are you imagining, exactly? >> >> Note that just because two schemas are "compatible" as checked by >> CompatibilityChecker does not prove that they are compatible at the >> application level. So, CompatibilityChecker can't really prove >> compatibility -- it can only prove incompatibility, in cases where the >> schemas are plainly mismatching. >> >> CompatibilityChecker could be used, for example, in a git commit hook, to >> check for changes made to a capnp file that appear to introduce >> incompatibilities. But, in this role it would be like a linter -- it can't >> catch all bugs, just some obvious ones. >> >> I would be wary of relying on CompatibilityChecker for correctness at >> runtime as part of a "negotiation", since it could falsely claim >> compatibility between protocols that aren't actually compatible. >> >> With all that said, although CompatibilityChecker isn't directly exposed >> as a public API today, you can access its functionality by creating a >> SchemaLoader and loading the two schemas you want to check into it (making >> sure they have the same type ID). If it detects they are incompatible, this >> will throw an exception. >> >> -Kenton >> >> On Sun, Oct 15, 2017 at 10:06 PM, Liam Staskawicz <[email protected] >> <javascript:>> wrote: >> >> >> Greetings, >> >> I'm interested in negotiating/validating the compatibility of data types >> prior to establishing a session between two peers. >> >> I came across capnp::SchemaLoader::CompatibilityChecker and found it to >> be quite similar to & perhaps a good match for what I am interested in but, >> unfortunately, not part of the public capnp api. >> >> Would you recommend reimplementing the parts of CompatibilityChecker >> needed for my application? Is there any interest/value/sense in making it >> (or something like it) public, to allow for reuse instead? >> >> Thank you, >> Liam >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Cap'n Proto" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> Visit this group at https://groups.google.com/group/capnproto. >> >> >> > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
