Value and size constraints in DBus Introspection XML

[Matthew Bromley-Barratt]

Hello,

Apologies if this is a topic that has already gone over previously; the mail list archive is quite lengthy. Further apologies for my inadequate search abilities if I'm inadvertently kicking off some sort of fuss or being naïve in the ways of DBus. Assuming I'm not writing out of turn, I humbly hope the following may generate interest and debate. 

Tools like gdbus-codegen will take a file containing introspection xml and emit source code that will implements the interface. The comparison to other IDLs (GPB, Thrift, Cap'n Proto, XSD, etc) is natural. So I was wondering if there were room (an indeed appetite?) for an addition. When specifying method arguments, their name, type and direction can be defined. My suggestion is, how about value and size constraints too?

For example, an integer argument called "bearing" might from the service's point of view have a valid value between 0 and 359, every other value being invalid and, if not excluded, potentially leading to undesirable behaviour. Whilst we can hand write code to validate the value sent by a client, it would be so much nicer if code generators could generate this for us. However, they can't do so if the XML doesn't contain the constraints information. 

Similarly with array and string sizes; acceptable length ranges could be defined and adhered to.

Having the constraints expressed in the introspection XML and being implemented by code generators would mean that *almost* all aspects of the interface are enforced automatically, and recorded in only one place (the XML). Thus any generated code in any language gets the same rigorous enforcement. 

This could be useful as:

i) value and size constraints don't have to be communicated by some other more error prone means to developers

ii) during development a team can readily make alterations to an interface spec knowing that a mere recompilation will (at the very least) ensure that all clients / services are talking the same interface with the same constraints. Renaming arguments is a way of using compilers to point out areas of developed code that need to be changed accordingly.

iii) services with constraints checking automatically built in are no more or less resilient to being misused than ones where the checks are written by hand. However they're more readily and reliably developed.

iv) constraints defined in the XML could be picked up automatically by software testing tools / fuzzers / etc.

If such an addition did prove popular, it shouldn't mean altering the existing wire format; constraints checking is a function of the end points, not the wire in between. So it's something that could be transitioned to gradually. Services that did incorporate automatically generated constraints checks would still work with clients that didn't, so long as the client was actually honouring the constraints. If this revealed clients that were breaking the constraints, well that'd be interesting all of itself.

If the run-time overhead of constraints was not acceptable in released code, it would be easy to have the constraints code generation made optional. That way development could be helped by having the checking in place, but the released version runs quicker without it. Or it could be a run-time option, or be performed depending on the uid of the client.

The constraints probably should be optional in the introspection XML; constraints aren't always required.

An interface aspect not described is time - i.e. how often a method can be called. But I'm sure that could be included too in some way.

**Background**

I'm drawing my inspiration from ASN.1. This has constraints expression and checking built in, and it can get quite elaborate. I've successfully used it in anger in a quite large project (for those who already know of ASN.1 and are finding this miraculous, I was fortunate to be able to use mature commercial tools for it.  Open source tooling is improving). The point that I wish to convey is that the message interfacing rigour imposed on the developers by the constraints checking was, to various degrees, a) annoying for them to begin with, b) lead to a very smooth running project with very few integration or runtime issues. With constraints checking in DBus, that might bring similar benefits to developers.

**Detail**

For anyone interested in seeing just how elaborate ASN.1 constraints can get, take a look at Chapter 13 in http://www.oss.com/asn1/resources/books-whitepapers-pubs/dubuisson-asn1-book.PDF. Here's a few pointers to specific sections of interest:

13.4 Page 263, Value Range Constraint (constraining the values of numbers, e.g. 0..359), 
13.5 Page 266, Size Constraint (constraining the sizes of strings and arrays),
13.7  Page 271 Regular Expression Constraint (I've never found this actually implemented by any of the ASN.1 tools I've come across)
13.11 Page 285, Constraint Combinations and especially Figure 13.3 on page 286 (great for building up complex overall constraints from simpler ones). 
	
ASN.1 schema can also have values (as well as types) in them, and these can be used as constants in other constraints. One can define values:

MaxLen INTEGER ::= 10
MaxVal INTEGER ::= 2543

These can then be used elsewhere in constraints:

List ::= SEQUENCE (SIZE(0..<MaxLen)) OF INTEGER (0..MaxVal)

The better ASN.1 tools will include these values in the generated code, for use in developed code such as 

for (int j = 0; j < MaxLen; j++){...}. 

The net result is that project constants can also be defined in schema, and then don't have to be redefined in developed code. It works very well that way. Change the values in the schema, recompile, everything is updated.

I'm not suggesting that DBus replicates all or any of this exactly, or has anything whatsoever to do with ASN.1. But something akin to these ways of defining constraints and constraint constants might find favour with developers using DBus. 

Well, that's it. Any thoughts?

Best regards,

Matthew Barratt