Re: [PATCH] MI: Replace sequence number with ID

[Mohammad-Reza Nabipoor]

Hi, Jose.

On Mon, Aug 09, 2021 at 11:31:58PM +0200, Jose E. Marchesi wrote:
> 
> >
> > Currently each message has a sequence number (which is incremented by poke 
> > editor).
> > But there are two kinds of messages:
> >   1. (Request, Response) pairs
> >   2. Events
> >
> > For the req-res messages, the initiator is the "client" and for the 
> > evenets, the
> > initiator is the poke.
> 
> Right, so we have two different "namespaces" for message IDs.  One for
> responses and events (poke initiated) and another one for requests
> (client initiated).
> 
> > So, it makes more sense to deal with these two kinds of interactions 
> > differently.
> > With this new design, poke uses negative numbers to assign an identity to 
> > each
> > event, and client uses odd numbers to identify requests, and pokes responds 
> > with
> > even IDs.
> 
> Hmmm, isn't this negative/even/odd schema a bit overcomplicated?  Whats
> wrong with using positive consecutive numbers in both namespaces?
> 
> Like, requests will be IDed like 0, 1, 2, 3, ...
> Also, responses and events will be IDed like 0, 1, 2, 3, ...
> 


The reason was to make messages distinguishable by a unique ID in each session.

What about moving down ID down under the "data" field?
This way ID lives in the corresponding request, response or event namespace.

From

```json
{
    "id": 1,
    "type": 0,
    "data": {
        "type": 0
    }
}
```

to

```json
{
    "type": 0,
    "data": {
        "id": 1,
        "type": 0
    }
}
```

`ID=0` is a special case and used can be used to refer to an invalid message
(e.g., for reporting in INVREQ event, the `reqid` can be 0).


WDYT about having an uint32 ID for each request, response and event, instead of
a message level ID?


> > Writing tests is also easier with this new approach. Keeping track of IDs 
> > for
> > requests and events is much easier.
> 
> How so?  Responses to requests always refer explicitly to the request
> they are responding to...
> 

I make the whole expected message (including the ID) and then compare it with
the received msg, like this: `assert response == message(id=2, ...)`.
So, it's important for me that next assigned ID be predictable.



Regards,
Mohammad-Reza