https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/MDSAL-129 mdsal <p>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.</p> <p>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.</p> <p>In either event, this would drastically decrease the programmer knowledge required to write an MD-SAL app.</p> <p>Operating System: All<br/> Platform: All</p> MDSAL-129

Add syntactic sugar Java Map interface on top of MD-SAL lists

New Feature Resolved Done Unassigned Colin Dixon Tue, 16 Feb 2016 17:13:01 +0000 Mon, 20 Apr 2020 10:19:02 +0000 Mon, 20 Apr 2020 10:19:02 +0000 Binding API 0 5 <p>Couple of questions:<br/> 1) what would be the consistency model?<br/> 2) what would be the thread safety model?<br/> 3) I do not see how futures can be exposed via java.util.Map<br/> 4) I do not quite see how change notifications could be unified with java.util.Map</p> <p>(In reply to Robert Varga from comment #1)<br/> &gt; Couple of questions:<br/> &gt; 1) what would be the consistency model?</p> <p>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.</p> <p>&gt; 2) what would be the thread safety model?</p> <p>I'd say the same as if you had done the relevant transactions without making them related as if by a chain.</p> <p>&gt; 3) I do not see how futures can be exposed via java.util.Map</p> <p>You wouldn't, you would expose the actual values and wait for them to materialize.</p> <p>&gt; 4) I do not quite see how change notifications could be unified with<br/> &gt; java.util.Map</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>They could just write an app against a set of Java Maps.</p> <p><a href="https://jira.opendaylight.org/browse/MDSAL-434" title="Fix unordered keyed list mapping" class="issue-link" data-issue-key="MDSAL-434"><del>MDSAL-434</del></a> has changed List to Map in keyed lists. As far as proxying things around, that functionality is already covered by disting DOMDataBroker implementations, hence it is only a question of wiring for a particular use case.</p> Development External issue ID 5365 External issue URL Issue Type Rank 0|i02whr: