[sysrepo-devel] ?==?utf-8?q? new generation of sysrepo
Michal Vaško
mvasko at cesnet.cz
Thu Sep 6 06:19:55 UTC 2018
Hi Andrew,
my comments are inline.
On Wednesday, September 5, 2018 21:08 CEST, ANDREW LANGEFELD <andrew.langefeld at adtran.com> wrote:
> Hello Michal,
>
> Below are a few questions and feedback on the proposed design:
>
> > From slide 3: "No NACM":
>
> Are there plans to move NACM support to elsewhere (e.g., to netopeer2), or will the feature be removed altogether? We would prefer to see NACM continue to be available as a supported feature.
Yep, it will be fully supported, but only for NETCONF (in netopeer2).
> > From slide 3: "No SR_EV_VERIFY?"
>
> In the new design, will it still be possible for data subscribers to reject configuration changes, as is possible today? This is a desired use case that we would like to see continue to be supported.
It most certainly will be supported, we are just thinking about simplifying the callback design a bit.
> > From slide 15: Operational data subscription: xpath of the requested subtree
>
> In the current implementation, sr_dp_get_items_subscribe() is limited to generic xpaths. Specifying list key values is not supported. Are there plans to improve this in the new design? In other words, will <get> <filter> content matches be supported? (This could improve queries for large lists.)
Yes, we are planning to support this.
> > From slide 26: Consistency example
>
> We're concerned about this example. A second commit should not be allowed to start while a first commit is in progress. Instead, commits should be considered atomic operations. We do not want to rely on client behavior (i.e., acquiring a lock) for this scenario to work properly; the server should enforce the correct behavior.
We are trying to design new sysrepo to be efficient. If, for example, you have a model for which there are 2 clients subscribed and handling completely independent subtrees, why forbid them to process changes concurrently? I can imagine a solution where you would define whether you require implicit commit locks for a particular model during its installation (or simply make it adjustable some other way).
Also, I am attaching the slides with some minor updates and in PDF format so that it can be opened anywhere without problems.
Regards,
Michal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new_sysrepo.pdf
Type: application/pdf
Size: 1009202 bytes
Desc: not available
URL: <http://lists.sysrepo.org/archives/sysrepo-devel/attachments/20180906/ab1c5898/attachment.pdf>
More information about the sysrepo-devel
mailing list