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 <l...@stask.net> 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 <l...@stask.net> 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 capnproto+unsubscr...@googlegroups.com.
> 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 capnproto+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/capnproto.

Reply via email to