Hello On 2021-05-09 at 05:46 -0400, Dave Mielke <[email protected]> wrote: > [quoted lines by Samuel Thibault on 2021/05/09 at 11:36 +0200] > >> Some bindings might wish to use a list rather than an array. > > > >If bindings want to return a list, fine for them, "array" is just a word > >for the brlapi protocol, it can be expressed whichever way is fine for > >bindings.
> They may wish to use an array for isArray==true but a list for > isArray==false. In other words, they may wish to use an array for a > multi-value result but a list for a multi-value single item. I think it's > healthy to make them aware of the difference. We are mixing different concepts now. I think that Samuel uses array as a term describing the data representation on the protocol level, whereas Dave uses it as a term to describe the logical language-level data type. What the client absolutely needs is: the basic data type of a single element in the parameter value – this is already provided. The client also needs the number elements in the parameter value – this should be provided by count, but it is not provided in case of strings. What the client does not necessarily need, but benefits from, is the semantic information on how to use/marshall/decode/encode this value. isArray alone cannot provide this information, as there are many languages with very different data types available – not just arrays and lists. For example one parameter (I don't remember which one) returns a bit vector, but this is not reflected in its properties in any way. My suggestion #1 is that if count == 0, the parameter contains a variable amount of values, and if it is positive, it contains exactly that many values. isArray is left for describing the intended logical use for the value – not its representation. My suggestion #2 is that count contains the number of values returned, if isArray == false. If isArray == true, then count contains the maximum number of values that may be returned/stored. My suggestion #3 is that we add more fields (or change existing ones) to describe more precisely the type of the parameter. If this is chosen, I suggest that we craft this system from scratch, and drop backwards compatibility in order to avoid creating more mess. -- Aura _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.app/mailman/listinfo/brltty
