legacy-stats extension vs Online verificator for Homie 4

[scaprile]

Hi,
according to my understanding and the example, this is correct:

homie/ohsb987654/$state ready
homie/ohsb987654/$homie 4.0.0
homie/ohsb987654/$name SomeName
homie/ohsb987654/$extensions org.homie.legacy-stats:0.1.1:[4.x]
homie/ohsb987654/$stats/interval 300
homie/ohsb987654/$stats/uptime 1
homie/ohsb987654/$nodes switch

However, verification fails:

Validation result: Validation failed
[object Object]1	Device 'ohsb987654' has the deprecated attribute '$stats' set! Please check with the newest version of the convention.

[davidgraeff]

True. Extensions are not supported by the verification tool.
And as long as we do not write extensions down in a machine readable way, that cannot really be fixed I guess.

We could allow extension writers to also write a javascript function verify(syntax_tree) -> bool that could be dynamically imported by the tool.

[scaprile]

Hi David,
I see it from a device developer perspective, I'm checking my code and trusting the tool.
With the backwards compatible way you guys followed for stats (and fw), I guess the validator should check the presence of that extension and (if not verify at least just) tolerate the presence of the $stats and $stats/+ entries; informing extensions are not checked.
I don't know for other extensions, I guess as long as they live in a known space they can be ignored by the validator until there is a proper mechanism. Something like grouping them all under a common tree.
Regards

I would somehow consider the legacy stats and the legacy firmware extensions to be some kind of "official extensions", since they use the org.homie. identifier (and according to the extension spec homie is a reserved keyword). Therefore it might be an good idea to include these two extensions into the validator.

As for the other extensions I currently see no easy way to include them into the validator.

[scaprile]

@EPNW , that is OK. The point I'm trying to raise is the fact that the validator rejects correct code. If extensions are present, they should at least not be marked as errors. I understand this can be hard when they can spread their topics everywhere. One thing that comes to my mind is to (for example) build a table of base topics for each known extension id. This way, whatever is below the base topic can be easily ignored. Entries in this table can be registered when the extension is registered. Sort of:

extension id                   base topic (after device id)
------------------------------------------------------------
org.homie.legacy-stats:*       $stats/#
org.homie.legacy-firmware:*    $localip,$mac,$fw/#
eu.epnw.meta:*                 +/$tags,+/$meta/#,+/+/$tags,+/+/$meta/#

Beyond that, also checking for correct posting for stats and firmware is a bonus.
Then, for other extensions, David's idea can be triggered at topic matching... just my 2 cents.

[davidgraeff]

Hm. The base topic idea is nice but basically disables the validator for certain topic branches.
Afaik we already have a machine readable list of extensions somewhere.

I suggest to make it mandatory for an extension author to create a js validation method (API to be defined). The hard part is already done (parsing the input into a tree structure with context data). A lazy author could just go with a loop, a condition and a regex expression. If no js routine can be found for an extension, that extension is not considered for the validator (like it is now).