[MDSAL-129] Add syntactic sugar Java Map interface on top of MD-SAL lists Created: 16/Feb/16 Updated: 20/Apr/20 Resolved: 20/Apr/20 |
|
| Status: | Resolved |
| Project: | mdsal |
| Component/s: | Binding API |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | ||
| Reporter: | Colin Dixon | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Description |
|
It would be nice to be able to pass the path (instance identifier) to a YANG list in the MD-SAL and have that return an MD-SAL-backed Java map that would listen to updates and translate put/deletes into appropriate transactions into the MD-SAL. This would have to have a few quirks to handle possibly failing transactions (do mutating calls block, return a Future, or something else?) as well as possibly provide notifications on changes. In either event, this would drastically decrease the programmer knowledge required to write an MD-SAL app. |
| Comments |
| Comment by Robert Varga [ 22/Feb/16 ] |
|
Couple of questions: |
| Comment by Colin Dixon [ 12/Apr/16 ] |
|
(In reply to Robert Varga from comment #1) It could be configurable, but I think the simplest way to do it would be to have every put/putAll create a write-only transaction, have ever get do a read-only transaction and and have an iterators over the entryset/keyset be based off of one read transaction. > 2) what would be the thread safety model? I'd say the same as if you had done the relevant transactions without making them related as if by a chain. > 3) I do not see how futures can be exposed via java.util.Map You wouldn't, you would expose the actual values and wait for them to materialize. > 4) I do not quite see how change notifications could be unified with In my mind, you should be able to to register for a notification on a key and have a callback whenever the value at that key changes. Under the hood it would just register on the IID to the list and the key and when the DCN fired it would make the callback with the value. |
| Comment by Colin Dixon [ 28/Jul/16 ] |
|
Just adding one more idea here. If you had this implemented, you could have two different backing implementations: one using MD-SAL binding APIs and another using RESTCONF calls. Assuming you could figure out how to cleanly generate the Java YANG bindings from the YANG file without the need for Maven, you could then (at least in theory) have a standalone Java app written against OpenDaylight where the developer wouldn't need to understand Karaf, OSGi, Maven, the MD-SAL internals or anything. They could just write an app against a set of Java Maps. |
| Comment by Robert Varga [ 20/Apr/20 ] |
|
|