New features with libyang
Closed this issue · 7 comments
Hi,
I am currently involved in the sysrepo/netopeer2 project. They have the yang parser libyang, which is written in C.
We would like to use libyang library with your netconf library to enhance it with new features, like for an example add partial XPATH support, something similar to sysrepo's XPATH implementation.
Are you open for cooperation on this subject?
Currently libyang has only pcre for it's external dependencies. We could package the libyang library into a GO package so the user does not need to install libyang locally on the machine.
The most relevant links from the sysrepo/netopeer2 project are:
libyang
sysrepo
Netopeer2
Best regards,
Mislav Novakovic
@mislavn Have you considered other libraries in Go like https://github.com/openconfig/goyang for integration?
@ydnath we have looked at other yang parsing libraries but we would like to use libyang because we are involved with the project, they are currently working on yang 1.1 which few other libraries have and people are starting to use libyang in production alongside sysrepo (sysrepo uses libyang).
I understand your concern that for Go programmers it will be harder to use C library via Cgo than native Go library but we will add documentation and examples for that.
We could also build the features so that it leaves room for other Go yang libraries.
If you have other concerns please feel free to voice them.
I don't think that yang (cgo or not) should be added to the netconf package. We should try to keep them seperate but have tight integration where it makes sense.
If there is a good way to define an interface in the netconf package that allows other packages like a libyang based module to serialize and create the RPC method then that would be prefered.
What did you have in mind for integration. More specifics would be good and maybe we can find what interfaces and APIS are needed in netconf package to support yor libyang package, goyang, or whatever else.
I understand you point of view, we can work on this in a separate Go project and link to your library or fork your project. I think for now I will need to use only your raw method netconf functions.
When the features are finished we can discuss if you want to use them in your project.
Some of the features we would like to add are:
1). Xpath support.The netconf API could look something like this
netconf-libyang.< Get | Set | Delete >(datastore, xpath, value). I would need to download the yang schema from the server in order to be able to transform the xpath into XML with libyang or have the locally avalaible.
2). CLI autocompletion on the xpath. While typing we would autocomplete or suggest: yang schemas, containers, leafs, groups, key names and so on.
3.) Testing framework with json as a config file. The json would specify the datastore, xpath, list of input values and a list of expected values for every get/set operation. We could also autogenerate tests for leafs based on their type in the yang model.
So libyang would mostly be used for transforming yang's xpath into xml or if we need the type of a leaf. We would need to download yang schemas from the server so libyang can parse them.
As for a concrete interface I don't have anything now for suggestion but I will keep it on mind when we design the system.
1). Xpath support.The netconf API could look something like this
netconf-libyang.< Get | Set | Delete >(datastore, xpath, value). I would need to download the yang schema from the server in order to be able to transform the xpath into XML with libyang or have the locally avalaible.
Since this package never deals with the XML directly this won't be added
2). CLI autocompletion on the xpath. While typing we would autocomplete or suggest: yang schemas, containers, leafs, groups, key names and so on.
There is no CLI here. You could create a package that implements a CLI then uses the netconf package for communication
3.) Testing framework with json as a config file. The json would specify the datastore, xpath, list of input values and a list of expected values for every get/set operation. We could also autogenerate tests for leafs based on their type in the yang model.
Like wise. Think of the netconf go package as just the transport and low level communication, you can use it to implement what you want, but it shouldn't actually deal with the request or responses directly.
Closing for now.