The more I think of it, the more I come to the conclusion that I should just 
use "const" fields and only model real fields for the actual information. This 
dramatically reduces the memory footprint of the model and simplifies working 
with objects as all you have are some simple properties like 
"subscriberProcessIdentifier" and don't need to construct or navigate through 2 
additional object layers.

It is some more work in modeling the spec but copy +paste is my friend 😉


Holen Sie sich Outlook für Android<>

From: Christofer Dutz <>
Sent: Saturday, September 21, 2019 4:10:34 PM
To: <>
Subject: [CODEGEN] Some thoughts "restrictions" of types

Hi all,

In the BACnet protocol I encountered something new (Who would have thought?)

Here sort of everything is encoded with so called Tags. These have a fixed 
structure and a variable payload.
Now depending on the type of request there are fixed sequences of tags coming 
in. So the first Tag has meaning X, the seconds Y, …
The thing is I would like to sort of say: Here comes a Tag, but with fixed 
portions set to certain values.

So let’s take the BACnetTag definition:

[discriminatedType 'BACnetTag'
    [simple        uint 4 'typeOrTagNumber']
    [discriminator uint 1 'contextSpecificTag']
    [simple        uint 3 'lengthValueType']

And a the following request:

['0x05' BACnetConfirmedServiceRequestSubscribeCOV
    [simple BACnetTag 'subscriberProcessIdentifier']
    [simple BACnetTag 'monitoredObjectIdentifier']
    [simple BACnetTag 'issueConfirmedNotifications']
    [simple BACnetTag 'lifetime']

It is not 100% correct, because I am expecting a tag with:
Type = 0
Context = 1
Length = 1
Which 1-byte payload is treated as 'subscriberProcessIdentifier'
So I sort of need to come up with a notation for this … any ideas?


Reply via email to