Maybe, but just maybe, we need another concept - a type resolver which
can traverse and decompose any tag?
In the end with more complex protocols we can have nested structures of
any depth, so things sooner or later will be nested many times.
Best,
Łukasz
On 16.09.2024 10:41, Christofer Dutz wrote:
Hi all,
I just came up with a different idea … we could add an “resolveArrays” method,
that returns a browseItem, where the arrays are resolved as children.
So as in below example the BrowseItem would have been a
SomeMultiDimensionalArrayVariable ([1..4][3..5])
* ChildProp1
* ChildProp2
Then the resolve array would return as below, where for example “[3]” is a
child of “SomeMultiDimensionalArrayVariable”
I am just trying to avoid clients from having to implement the resolving of
addresses in a too complex way.
I think my UI experiment is a great example of such a tool and how people would
use our API.
If we had an implementation such as the one, I mentioned, I think things would
be a lot simpler.
The original would be the more formally correct version, the resolved version
would be the more usable version.
Chris
Von: Christofer Dutz <christofer.d...@c-ware.de>
Datum: Montag, 9. September 2024 um 19:22
An: dev@plc4x.apache.org <dev@plc4x.apache.org>
Betreff: AW: [DISCUSS] How should the browse api handle arrays?
Soooooo,
Currently trying to think of ways how to return things correctly in our browse
API. Assuming we’re following option 2 and we want to do all the work in the
browse part of the driver.
When we have non-array items it’s pretty trivial and in case of a struct type,
the children simply reflect the child structure of the parent.
However, how should we handle arrays? I currently am leaning towards
considering the array dimensions as “children” … so if we have a
two-dimensional array of a struct, it would look something like this:
SomeMultiDimensionalArrayVariable ([1..4][3..5]):
* [1]: ([3..5])
* [3]:
* ChildProp1
* ChildProp2
* [4]:
* ChildProp1
* ChildProp2
* [5]:
* ChildProp1
* ChildProp2
* [2]: ([3..5])
* [3]:
* ChildProp1
* ChildProp2
* [4]:
* ChildProp1
* ChildProp2
* [5]:
* ChildProp1
* ChildProp2
* [3]: ([3..5])
* [3]:
* ChildProp1
* ChildProp2
* [4]:
* ChildProp1
* ChildProp2
* [5]:
* ChildProp1
* ChildProp2
* [4] : ([3..5])
* [3]:
* ChildProp1
* ChildProp2
* [4]:
* ChildProp1
* ChildProp2
* [5]:
* ChildProp1
* ChildProp2
Each node would have array information so some more advanced tooling could make
use of it (in round braces)
Chris
Von: Christofer Dutz <christofer.d...@c-ware.de>
Datum: Montag, 9. September 2024 um 10:17
An: dev@plc4x.apache.org <dev@plc4x.apache.org>
Betreff: AW: [DISCUSS] How should the browse api handle arrays?
I just remembered another bonus of option 2 that I had been thinking about
yesterday:
If the client needs to build the address based on templates sent from the API
(like in option 1), the client needs to know the assembly rules of the
corresponding protocol.
Simply using a “.” as separator might not be valid for all protocols. By
sending fully exploded browse items, we give the driver implementation 100%
control, over this (and keep this complexity away from our users).
Chris
Von: Christofer Dutz <christofer.d...@c-ware.de>
Datum: Montag, 9. September 2024 um 10:10
An: dev@plc4x.apache.org <dev@plc4x.apache.org>
Betreff: [DISCUSS] How should the browse api handle arrays?
Hi all,
While working on my little side-project (which actually puts together all the
APIs for me for the first time) I noticed that currently the browse API has
it’s shortcomings when it comes to handling arrays.
For example, the fully qualified address:
MAIN.hurz_STRUCT_ARRAY[2].hurz_DATE
Is returned as:
MAIN.hurz_STRUCT_ARRAY.hurz_DATE
Omitting the array portion.
Now I could think of multiple ways to handle this:
1. We return one item with the full dimensions:
MAIN.hurz_STRUCT_ARRAY[1…3].hurz_DATE
2. We return one item per array item:
MAIN.hurz_STRUCT_ARRAY
MAIN.hurz_STRUCT_ARRAY[1].hurz_DATE
MAIN.hurz_STRUCT_ARRAY[2].hurz_DATE
MAIN.hurz_STRUCT_ARRAY[3].hurz_DATE
I would assume option 2 makes integration into other systems a LOT simpler, but
extend the size of the response dramatically.
Considering that the browse functionality would only be used occasionally, I
would lean more towards option 2 … mainly because this way users of the API
don’t have to post-process the responses.
Hereby they can do less errors or misinterpret things.
What do you think?
If I don’t hear any feedback, I’ll start working on implementing option 2 this
Friday.
Chris
