<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-7">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoPlainText">>> Whenever I've found myself having interdependencies between message
<o:p></o:p></p>
<p class="MsoPlainText">>> fields ... I've often found that that's an indication that I'm not
<o:p></o:p></p>
<p class="MsoPlainText">>> constructing a very good schema.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">>Consider a simple example, where I have the heating in my office controlled by a Raspberry ð, and the server process accepts control messages via D-Bus. I can >send it a temperature at which to switch on, and another temperature at
which to switch off. The first temperature must be lower than the second one. Getting >these the wrong way round could lead to a thermal runaway situation that makes my office a rather unpleasant place to be in.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Well now, we wouldn’t want that!<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">In that example I’d say that alternative parameters might be the first temperature with a constrained range, and a delta temperature which must be positive and also with a constrained range. That takes care of the second temperature
having to be higher than the first. <o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Though of course this is imperfect. If there’s a maximum that the second temperature must not exceed and if the system allows the first temperature to be closer to that than the largest permitted delta, simple value constraints don’t
fully enforce the rules. Whether one is actually better off as a developer is questionable; one would end up with heating that doesn’t run away, but never switches off. You’d be in just as unpleasant a situation, but at least it was because you’d asked to
be; the first temperature has to be close to system maximum temperature.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">So this is indeed an easy example on the limitations on what I’m suggesting. However, I contend that an option to constrain values / sizes is worth it as there’s plenty of situations where that simple approach is sufficiently exact.
<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Do you think it’d be worth the bother of implementing all that would be necessary (principally, changing the code generators, etc.)? I’ve no idea of the bug rate actually encountered in Dbus servers due to a failure to validate parameters
/ lengths properly. Have services been broken by sending arrays that are too large, or out of spec values? Is such an event of any real consequence if all the services one is typically permitted to interact with are all running at the same user privileges?
<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I’m quite happy if the consensus is “not worth it” <span style="font-family:Wingdings">
J</span> <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>