Skip to main content

check_compatibility

Function check_compatibility 

Source
pub fn check_compatibility(client: &ClientClaim) -> Compatibility
Expand description

Decide whether a client can drive THIS engine.

Evaluated against the engine’s own tables, never against anything in the claim beyond the claim’s requirements. That is the whole design: the client supplies the question, the engine supplies the answer.

§The grammar-digest rule

A digest mismatch alone is a GAP, not a refusal. Two reasons. A client may legitimately implement a subset — a scripting binding that only ever emits FROM c WHERE k = v does not care that the engine also has TRAVERSE, and refusing it would be refusing a client that works. And the surface description is versioned, so a mismatch can also mean “same language, different encoder generation”, which is not a language difference at all.

But a mismatch stops being harmless the moment the client REQUIRES something whose meaning is fixed by the grammar. nql.where.regex_subset is not a flag the engine can promise in the abstract; it names a specific set of accepted patterns, and if the two sides do not agree on the grammar they do not agree on which set. Answering “yes, supported” there would be exactly the self-hashing failure in a new costume — a confident yes backed by nothing the two parties actually share. So: digests differ AND a required capability is grammar-defined → Incompatible, naming the capability and both digests.