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 <l...@code-house.org> Datum: Montag, 16. September 2024 um 11:49 An: dev@plc4x.apache.org <dev@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 <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 >
