Operating System: Mac OS
Platform: PC

Instance IDentifier provides utilities
such as
create().

Instance Identifier allows for fluent APIs and creating child identifiers from parent ones:
NODE_ID = InstanceIdentifier.create(Nodes.class).child(Node.class,new NodeKey("foo"));
AUG_ID = NODE_ID.augmentation(NodeAugmentation.class);

I don't think Devin is referring to the InstanceIdentifier API but figuring out how to build correct a IID from a yang data model, i.e. what generated classes to use and how to stitch them together.

One thing is to eliminate the need for explicitly specifying augmentation, Eg instead of:

InstanceIdentifier.create(Nodes.class)
.child(Node.class,new NodeKey("foo"))
.augmentation(NodeAugmentation.class);

possibly:

InstanceIdentifier.create(Nodes.class)
.child(NodeAugmentation.class,new NodeKey("foo"));

The API could implicitly figure out that NodeAugmentation augments Node.

It would be really cool if the generated code had a static getInstanceIdentifier() method. So one could simply call NodeAugmentation.getInstanceIdentifier(NodeKey nodeKey) and let that build it for you.

At the very least, we could add helper classes for the common boilerplate stuff, eg NodeInstanceIdentifier.create(NodeKey nodeKey).

Move to MD-SAL, as it requires support from the binding spec.

https://git.opendaylight.org/gerrit/67909
https://git.opendaylight.org/gerrit/67910

Problem here is that we really need that Node.class, which means we need to reflect/cache NodeAugmentation.class shape, so we know to derive the type from 'implements Augmentation<Node>. That is doable.

Getting getInstanceIdentifier() ... I am not sure that's possible with the current state of affairs – I am afraid all we can do is getPathArgument(NodeKey) due to groupings and nested lists, but the problem is that:

• it bloats codegen classes
• it does not really save that much code