[RFC PATCH 00/10] ratp: new generic RATP command support

[Aleksander Morgado]

>>
>> The first patches (1-5) break the current RATP API, by introducing
>> the concept of requests, responses and indications:
>>  * Requests sent to one endpoint are expected to be replied with
>>    a response by the peer endpoint.
>>  * Indications are messages sent from one endpoint to another which
>>    are not expected to be replied.
>
> I do not see why we have to break the RATP API. I mean currently we
> have BB_RATP_TYPE_COMMAND and BB_RATP_TYPE_COMMAND_RETURN which you
> convert to .type = BB_RATP_TYPE_COMMAND, .flags = 0 | RESPONSE.
>
> I see that using flags looks somewhat nicer, but besides of that,
> what is your selling point to break the API?
>

Well, it was just easier to say "if I send a request of type X, I
expect back a response of the same type X". It avoids the need of
having to define which command id is expected as response for which
command id request. I don't think I have any other selling point :)
Being so early in the amount of commands we have in RATP, thought this
could be a good improvement. Maybe I'm biased because I'm used to
talking to mobile broadband modems, and that is how all protocols I
know are defined. That said, changing this to keep the API would still
be very easy, it's no big deal.

-- 
Aleksander
https://aleksander.es