You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Christofer Dutz <ch...@c-ware.de> on 2024/09/09 08:09:47 UTC
[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
AW: AW: [DISCUSS] How should the browse api handle arrays?
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Lukasz,
the problem I see here, is that this would need to be protocol specific (in theory).
Right now, I’ll be building a default implementation, that converts types with array coordinates into children using “[]” for the arrays and multiple dimensions as “[][][][]” and joins sub-type paths using “.” … As far as I have seen protocols supporting this sort of symbolic addressing all are using this form of notation, but I could imagine that there’s at least one type that uses something different (just because they can) and an address could be something like this:
someVariable(4,5,6)/subVariable
In that case we’d only need a resolver for that protocol.
Chris
Von: Łukasz Dywicki <lu...@code-house.org>
Datum: Montag, 16. September 2024 um 11:49
An: dev@plc4x.apache.org <de...@plc4x.apache.org>
Betreff: Re: AW: [DISCUSS] How should the browse api handle arrays?
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 <ch...@c-ware.de>
> Datum: Montag, 9. September 2024 um 19:22
> An: dev@plc4x.apache.org <de...@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 <ch...@c-ware.de>
> Datum: Montag, 9. September 2024 um 10:17
> An: dev@plc4x.apache.org <de...@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 <ch...@c-ware.de>
> Datum: Montag, 9. September 2024 um 10:10
> An: dev@plc4x.apache.org <de...@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
>
Re: AW: [DISCUSS] How should the browse api handle arrays?
Posted by Łukasz Dywicki <lu...@code-house.org>.
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 <ch...@c-ware.de>
> Datum: Montag, 9. September 2024 um 19:22
> An: dev@plc4x.apache.org <de...@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 <ch...@c-ware.de>
> Datum: Montag, 9. September 2024 um 10:17
> An: dev@plc4x.apache.org <de...@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 <ch...@c-ware.de>
> Datum: Montag, 9. September 2024 um 10:10
> An: dev@plc4x.apache.org <de...@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
>
AW: [DISCUSS] How should the browse api handle arrays?
Posted by Christofer Dutz <ch...@c-ware.de>.
But nevertheless …
as the amount of feedback here on this list is quite low … If I don’t hear any objections, I’ll just go ahead implementing it.
it would however be great to actively get consent, as that shows active approval and continuously doing things with timeouts is just stupid and slows things down.
Chris
Von: Christofer Dutz <ch...@c-ware.de>
Datum: Montag, 16. September 2024 um 10:42
An: dev@plc4x.apache.org <de...@plc4x.apache.org>
Betreff: AW: [DISCUSS] How should the browse api handle arrays?
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 <ch...@c-ware.de>
Datum: Montag, 9. September 2024 um 19:22
An: dev@plc4x.apache.org <de...@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 <ch...@c-ware.de>
Datum: Montag, 9. September 2024 um 10:17
An: dev@plc4x.apache.org <de...@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 <ch...@c-ware.de>
Datum: Montag, 9. September 2024 um 10:10
An: dev@plc4x.apache.org <de...@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
AW: [DISCUSS] How should the browse api handle arrays?
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <ch...@c-ware.de>
Datum: Montag, 9. September 2024 um 19:22
An: dev@plc4x.apache.org <de...@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 <ch...@c-ware.de>
Datum: Montag, 9. September 2024 um 10:17
An: dev@plc4x.apache.org <de...@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 <ch...@c-ware.de>
Datum: Montag, 9. September 2024 um 10:10
An: dev@plc4x.apache.org <de...@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
AW: [DISCUSS] How should the browse api handle arrays?
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <ch...@c-ware.de>
Datum: Montag, 9. September 2024 um 10:17
An: dev@plc4x.apache.org <de...@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 <ch...@c-ware.de>
Datum: Montag, 9. September 2024 um 10:10
An: dev@plc4x.apache.org <de...@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
AW: [DISCUSS] How should the browse api handle arrays?
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <ch...@c-ware.de>
Datum: Montag, 9. September 2024 um 10:10
An: dev@plc4x.apache.org <de...@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