We would like to add to MD-SAL the ability to make it searchable so that users of the MD-SAL don't have to always read everything and manually search for the content they want.

Use cases:

Find me an instance of X, which has
a leaf xyz attribute definedA leaf with value abc
I.e. Find me the node which has at least one node-connector
A leaf with value abc
I.e. Find me the node with name= ‘node123'
A leaf with value != abc
Find me the node that does not have ‘openflow’ in it
A node in a child list which has value abc
Find me the node, who has a node connector, with Ipaddress “192.168.1.1"
A grandchild node which has value abc
Find me the node who has an openflow statistic ‘abc’=123
Any of the above with multiple criteria ("and" and "or" options)

give me the source termination point of link 'foo'

While not specifically raised, I could see requests coming in for the ability to search data provided on data listeners as well. With that said, I think that is OUTSIDE the scope of this milestone (and a new milestone should be added for that).

Pagination / sorting of responses came up - I believe that should be handled outside of this MILESTONE as there are benefits of that without searching.

=====
Suggested Implementations:

1) We should strongly consider using a subset of functionality of XPATH as XPath is a query language for DOM (Tree) data stores - no sense in reinventing the wheel here. It sounds like in general we can probably always return a node, vs returning individual values, but that is something we will have to experiment with as we move forward.

2) There is a suggest raised that we allow searching to happen in the datastores them selves so that we don't have to return all matching data to then search it (i.e. allow data stores to optimize the searches)

3) Even though the data store may optimize the search, some data stores may not add that capability. We should consider adding a default (initial implementation) that doesn't require data stores to search. That way we get immediate functionality compatible with all data stores. Then data stores can optimize in the future.

4) We can consider an optimization (helper) functions that allow a user to specify a root of the data tree to help filter down the initial request - in stead of starting at the true root, we could start 3 levels down a branch which could significantly impact search times.