[sysrepo-devel] ?==?utf-8?q? sysrepo API change

[Michal Vaško]

Hi Joan,
no, sr_val_t will NOT be changed so no refactoring will be needed if you use only that.

Regards,
Michal

On Wednesday, August 29, 2018 13:35 CEST, Joan Landry <JoLandry at advaoptical.com> wrote: 
 
> Will any refactoring be required for sr_val_t?
> If so can you provide an example of the type of refactoring that will be required.
> Thanks,
> Joan Landry
> 
> -----Original Message-----
> From: sysrepo-devel <sysrepo-devel-bounces at sysrepo.org> On Behalf Of Michal Vaško
> Sent: Wednesday, August 29, 2018 4:42 AM
> To: sysrepo-devel <sysrepo-devel at sysrepo.org>
> Subject: [sysrepo-devel] sysrepo API change
> 
> Hi everyone,
> we would like to receive feedback on an API change we are planning. There is a good chance the majority of sysrepo clients will not be affected at all but that is exactly what we are trying to find out.
> 
> Currently, there are 2 API variants for many functions. These functions are either without a suffix or end with "_subtree". Namely, sr_action_send(), sr_action_subscribe(), sr_event_notif_send(), sr_event_notif_subscribe(), sr_rpc_send(), sr_rpc_subscribe(). Additionally, there are pairs sr_get_item*() and sr_get_subtree*(). Functionality of these functions is the same except they return any nodes either in sr_val_t structures or sr_node_t structures. We would like to remove sr_node_t structures altogether and replace them with a libyang native data tree format struct lyd_node *. This format will also be much more efficient to work with than both sr_node_t and sr_val_t.
> 
> TLDR; Do you have any clients using the subtree API variant of sysrepo functions (that work with sr_node_t)? If so, are you strongly against changing those structures to the libyang struct lyd_node *? All the information in sr_node_t can be also read from lyd_node but it would require some refactoring of your code.
> 
> Thank you for any feedback.
> 
> Regards,
> Michal
> _______________________________________________
> sysrepo-devel mailing list
> sysrepo-devel at sysrepo.org
> http://lists.sysrepo.org/listinfo/sysrepo-devel