Re: RFC: New model for stream messages

Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
 

+1 in general, but we should be careful
with respect to clients.

Perhaps choose a suffix different from _dump,
so users can infer the return value structure more easily?

Vratko.

-----Original Message-----
From: vpp-api-dev@... <vpp-api-dev@...> On Behalf Of Dave Wallace
Sent: Tuesday, 2019-June-18 16:12
To: vpp-api-dev@...
Cc: Dave Barach (dbarach) <@vppguy>
Subject: Re: [vpp-api-dev] RFC: New model for stream messages

+1

On 6/18/2019 3:02 AM, Ole Troan wrote:
Hi,

Dave made a suggestion to get rid of the control_ping wrapper hack that we use to detect last message in a stream for dump/details.

We have implemented something in:
https://gerrit.fd.io/r/#/c/20191/

Instead of having to wrap dump/detail calls in control ping, send
details messages in between a normal reply / request pair. As expressed in the below service statement.

Example:

service {
rpc map_domain_dump returns map_domain_dump_reply
stream map_domain_details;
};

autoreply define map_domain_dump
{
u32 client_index;
u32 context;
};

define map_domain_details
{
u32 context;
u32 domain_index;
vl_api_ip6_prefix_t ip6_prefix;
vl_api_ip4_prefix_t ip4_prefix;
vl_api_ip6_prefix_t ip6_src;
u8 ea_bits_len;
u8 psid_offset;
u8 psid_length;
u8 flags;
u16 mtu;
string tag[limit=64];
};


It's backwards compatible, so only those messages that have the service definition will use the new model.
But of course all language bindings will have to support this.

Views?

Best regards,
Ole

Join vpp-api-dev@lists.fd.io to automatically receive all group messages.