[BRLTTY] Low-level BrlAPI questions

[Aura Kelloniemi]

Hello

On 2021-05-09 at 05:46 -0400, Dave Mielke <Dave at mielke.cc> 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