1-indexing and 0=all, index in response

[tehn]

originally raised by @ngwese

frequently we have a getter/setter that has an index, ie ansible has four tracks so the "note" getter will be asking which track.

1. 1-indexing with 0 indicating "all"

• standardize 1-based indexing
• index 0 is the equivalent of 1..n

2. query responses include index

currently ii get queries require some state tracking from the requester.

standardizing the response to include the index (and even id) might clarify.

side note: 2D arrays (ie subindexes for parameters) are sometimes used.

[trentgill]

(1) sounds good to me.

re: (2) I'm not convinced we need to add this to the spec. My only experience is with the stm32 HAL libraries, but in that context this wouldn't avoid state tracking.

I2C transactions are blocking wrt the I2C hardware layer, so it seems acceptable to save the content of the current request until it returns.

Is there an example where this has been an issue?

[scanner-darkly]

re: 2 - would a multi leader setup play into this consideration? like 2 leaders requesting different index items from the same follower?

[ngwese]

for (1) an additional case to consider is that if 0=all what does that mean for get/query commands #6. right now on tt and crow people have to use loops to query the current state of each input on anisble, txi, etc.

(2) the note about queries including the index came up before i was remind the the i2c bus is synchronous in nature.

at the risk of getting off topic this is an instance where the language/api ux of programmable devices like teletype and crow collide with what is going on at the hardware level.

the reason i was interested in seeing an index included originally was actually triggered by crow's ii api where a get request is an async operation in lua and all the response get handled by a singular event handler which doesn't know which index the value corresponds to. for example if one wants to get the state of all txi inputs one currently has to do something like: (pseudo code)

for i = 1:4 do
  ii.txi.get('param', i)

...then in the event handler one gets:

ii.txi.event = function(name, value)
  -- for each 'param', value pair which index am i getting?
  ...
end

if ii.txi.get was synchronous then it would be obvious which index the value corresponds to.

given the synchronous nature of i2c it doesn't seem like communicating the index in the response over the wire so ultimately i think concern (2) is really about how crow exposes ii and not the protocol itself.

[trentgill]

@ngwese I think this is a crow-specific issue & the data is accessible in crow's low-level driver, just needs to be plumbed through. I made an issue on the crow repo.

2 leaders requesting different index items from the same follower?

@scanner-darkly I believe the expected behaviour here would be that one of the leaders would lose bus-arbitration when the channel bits diverged, then need to retry. I don't see how (2) changes anything there.

for (1) an additional case to consider is that if 0=all

I imagine in this case, a get request would just return a default value as it's not a valid request. It would be fun to have 'get all indices' but it raises a lot of questions (eg. multiple-return values, variable length, what would teletype do with the result?)