Discussion:
[capnproto] capnp::SchemaLoader::CompatibilityChecker
Liam Staskawicz
2017-10-16 05:06:29 UTC
Permalink
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+***@googlegroups.com.
Visit this group at https://groups.google.com/group/capnproto.
'Kenton Varda' via Cap'n Proto
2017-10-16 19:09:22 UTC
Permalink
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
Post by Liam Staskawicz
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
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+***@googlegroups.com.
Visit this group at https://groups.google.com/group/capnproto.
Liam Staskawicz
2017-10-18 00:03:12 UTC
Permalink
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
Post by 'Kenton Varda' via Cap'n Proto
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
Post by Liam Staskawicz
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
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+***@googlegroups.com.
Visit this group at https://groups.google.com/group/capnproto.
'Kenton Varda' via Cap'n Proto
2017-10-18 16:44:19 UTC
Permalink
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
Post by Liam Staskawicz
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
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
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
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+***@googlegroups.com.
Visit this group at https://groups.google.com/group/capnproto.
d***@gmail.com
2017-12-04 15:50:01 UTC
Permalink
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.
Post by 'Kenton Varda' via Cap'n Proto
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
Post by Liam Staskawicz
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
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
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
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+***@googlegroups.com.
Visit this group at https://groups.google.com/group/capnproto.
Loading...