Re: [capnproto] capnp::SchemaLoader::CompatibilityChecker

[deansherthompson]

The request for a public API for backward compatibility checking is in PR 
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  > 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 > > 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+...@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.

Re: [capnproto] Re: Working on Swift support

[deansherthompson]

Dan, I’m now at a point where I’d work on this. Would you be up for throwing 
what you have into GitHub?

Dean

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