RFC - Ember+ Templates Draft

[Hoffmann, Kimon (Lawo AG)]

Hi all,

I just wrote down a more formal proposal of the recently discussed
Templates extension to Ember+.
Please have a look at the attached document and, of course, any feedback
would be greatly appreciated!

Best regards,
Kimon

[Marius Keuck]

Hi Kimon,

 

many thanks for the draft, it is very well written and I think the proposal can be used to implement the template feature.

 

There are only two points I would like to discuss this afternoon:

- Does it make sense to allow template definitions for matrices and functions? I think the benefit of specifying templates only for a matrix or function is quite small. But on the other side I also think the less exceptions we have the easier it is to understand and implement it - so allowing it should be the better way for people implementing a consumer or provider.

- Can we afford to change the semantics of the DirFieldMask.Default flag (from All to Sparse)? Probably most consumer implementations do not specify a mask at all, which results in a mask of "Default" (0). So changing the meaning of that flag might result in consumers no longer working correctly.

 

 

Mit freundlichen Grüßen/Best regards

 

 

Marius Keuck

- Software Development -

 

Phone:  +49 (611) 262 390 - 82

Fax:      +49 (611) 262 390 - 98

Mobile:  +49 (170) 7976655

 

 

L-S-B Broadcast Technologies GmbH

Konrad-Adenauer-Ring 13-15, D-65187 Wiesbaden

Amtsgericht Wiesbaden HRB 26167

Geschäftsführer: Frank Sucky, Wilfried Luff

 

Disclaimer

As this message might contain confidential information, please notify the sender if you have received this e-mail by mistake. The sender accepts no liability for any damage caused by any information or virus transmitted by this email.

--

You received this message because you are subscribed to the Google Groups "ember-plus-development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ember-plus-develo...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Hoffmann, Kimon (Lawo AG)]

Hi all,

Here is a small update to the initial draft. In the initial draft the
wording in the section „Constness“ was wrong, expressing the opposite of
what was intended.
Thanks to Johannes for bringing this error to my attention!

Best regards,
Kimon

[Hoffmann, Kimon (Lawo AG)]

Hi Marius,

>- Does it make sense to allow template definitions for matrices and
>functions? I think the benefit of specifying templates only for a matrix
>or function is quite small. But on the other side I also think the less
>exceptions we have the easier it is to understand and implement it - so
>allowing it should be the better way for people implementing a consumer
>or provider.

While I also think that template references for these two element types
are probably of little benefit, I included them for the sake of uniformity.

>- Can we afford to change the semantics of the DirFieldMask.Default flag
>(from All to Sparse)? Probably most consumer implementations do not
>specify a mask at all, which results in a mask of "Default" (0). So
>changing the meaning of that flag might result in consumers no longer
>working correctly.
>
>

Yes, you are probably right about this. Leafing the default as is would
also make it easier for consumers to become compatible with the extension
without the need to implement any new logic aside from discarding the new
element type and attributes.

Best regards,
Kimon

[Huber, Andreas (LES Switzerland GmbH)]

Hi

Thanks for the template draft. I have the following questions:

1. Shouldn't there also be a QualifiedTemplate?
2. If I interpret the draft correctly, then a provider would report a template as follows:

<Event type="Message" timeUtc="16:12:57.77" direction="Consumer to Provider" number="1">
<Slot>00</Slot>
<Command>EmberData 01 1E 02</Command>
<Payload>
<Root type="RootElementCollection">
<RootElement type="Command">
<number type="Integer">32</number>
</RootElement>
</Root>
</Payload>
</Event>
<Event type="Message" timeUtc="16:12:57.95" direction="Provider to Consumer" number="1">
<Slot>00</Slot>
<Command>EmberData 01 14 02</Command>
<Payload>
<Root type="RootElementCollection">
<RootElement type="Template">
<number type="Integer">2</path>
<contents type="Set">
<identifier type="UTF8String">_1</identifier>
<description type="UTF8String">Devices</description>
<isOnline type="Boolean">true</isOnline>
</contents>
</RootElement>
<!-- more RootElements -->
</Root>
</Payload>
</Event>

Correct? If so, then I would argue that a template should somehow indicate what type of element it describes, probably by introducing 8 new different types (ParameterTemplate, QualifiedParameterTemplate, NodeTemplate, ...) instead of just one. This would make it significantly easier for a consumer to read and store a template "on the fly".

Thanks & Regards,

Andreas

> -----Original Message-----
> From: ember-plus-...@googlegroups.com [mailto:ember-plus-
> devel...@googlegroups.com] On Behalf Of Hoffmann, Kimon (Lawo
> AG)

[Hoffmann, Kimon (Lawo AG)]

Hi Andreas,

Thanks for taking the time to review the draft!

>1. Shouldn't there also be a QualifiedTemplate?

Yes, you are probably right, although I’m not entirely sure about this. Is
a QualifiedXXX a valid response to an enumeration initiated by a
GetDirectory request? Because if the QualifiedXXX types are only used for
change notifications a QualifiedTemplate cannot occur by definition.

>2. If I interpret the draft correctly, then a provider would report a
>template as follows:
>

> [...]

>
> <RootElement type="Template">
> <number type="Integer">2</path>
> <contents type="Set">
> <identifier type="UTF8String">_1</identifier>
> <description type="UTF8String">Devices</description>
> <isOnline type="Boolean">true</isOnline>
> </contents>
> </RootElement>
>

> [...]

>
>Correct? If so, then I would argue that a template should somehow
>indicate what type of element it describes, probably by introducing 8 new
>different types (ParameterTemplate, QualifiedParameterTemplate,
>NodeTemplate, ...) instead of just one. This would make it significantly
>easier for a consumer to read and store a template "on the fly".

If I’m not completely mistaken about the ASN.1 CHOICE type, the example
structure you posted lacks on level of indirection:

[...]
<RootElement type="Template“>
<Element type="Node">

<number type="Integer">2</path>
<contents type="Set">
<identifier type="UTF8String">_1</identifier>
<description type="UTF8String">Devices</description>
<isOnline type="Boolean">true</isOnline>
</contents>

</Element>
</RootElement>
[...]

If this is the case, it should not be necessary to add four (or eight)
distinct template types. But even then one could argue that doing so makes
the representation slightly more efficient by avoiding this level of
indirection that introduces an additional frame in the encoding.


BTW: This (possibly incorrect) interpretation of the ASN.1 CHOICE type was
the reason why I added the first sentence to the „Template Identity“
section:
„The number of a template is the number of its contained element
definition.“


Best regards,
Kimon

[Huber, Andreas (LES Switzerland GmbH)]

Hi Kimon

> Yes, you are probably right, although I’m not entirely sure about this. Is
> a QualifiedXXX a valid response to an enumeration initiated by a
> GetDirectory request?

I would say so, yes. At least I don't remember seeing any such restriction in the specs.

> Because if the QualifiedXXX types are only used for
> change notifications a QualifiedTemplate cannot occur by definition.

For a node template, the consumer still needs to discover the internal structure via appropriate GetDirectory requests, right? If so, the consumer might want to use QualifiedTemplate to save traffic.

> If I’m not completely mistaken about the ASN.1 CHOICE type, the example
> structure you posted lacks on level of indirection:
>
> [...]
> <RootElement type="Template“>
> <Element type="Node">
> <number type="Integer">2</path>
> <contents type="Set">
> <identifier type="UTF8String">_1</identifier>
> <description type="UTF8String">Devices</description>
> <isOnline type="Boolean">true</isOnline>
> </contents>
> </Element>
> </RootElement>
> [...]

I don't follow, the situation seems to be exactly the same as for Root and RootElementCollection, there we don't have such an indirection/wrapping either.

Regards,

Andreas

> -----Original Message-----
> From: ember-plus-...@googlegroups.com [mailto:ember-plus-
> devel...@googlegroups.com] On Behalf Of Hoffmann, Kimon (Lawo
> AG)
> Sent: Friday, June 6, 2014 12:54
> To: ember-plus-...@googlegroups.com
> Subject: Re: RFC - Ember+ Templates Draft
>

[Hoffmann, Kimon (Lawo AG)]

Hi all,

I have just updated the draft to revert the change to the default
DirFieldMask and have attached the most recent revision to this mail.
I will attend to the changes suggested by Andreas in a later revision.

Best regards,
Kimon

[Hoffmann, Kimon (Lawo AG)]

....And here is the attachment. ;)