13:54:29 <devinavery> #startmeeting md-sal-query
13:54:29 <odl_meetbot> Meeting started Fri Aug  8 13:54:29 2014 UTC.  The chair is devinavery. Information about MeetBot at http://ci.openstack.org/meetbot.html.
13:54:29 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:54:29 <odl_meetbot> The meeting name has been set to 'md_sal_query'
13:54:35 <devinavery> #chair regXboi
13:54:35 <odl_meetbot> Current chairs: devinavery regXboi
13:54:54 <devinavery> #info Neel has the normalized node printing out as discussed on Aug 7th.
13:55:06 <devinavery> #info ex: Normalized Node is : ImmutableContainerNode{nodeIdentifier=(http://netconfcentral.org/ns/toaster?revision=2009-11-20)toaster, value=[ImmutableLeafNode{nodeIdentifier=(http://netconfcentral.org/ns/toaster?revision=2009-11-20)toasterStatus, value=up, attributes={}}, ImmutableLeafNode{nodeIdentifier=(http://netconfcentral.org/ns/toaster?revision=2009-11-20)toasterManufacturer, value=Opendaylight, attributes={}}
13:55:06 <devinavery> , ImmutableLeaf
13:55:07 <regXboi> #link http://pastebin.com/mSX2kcHb
13:55:24 <devinavery> #info see link for full detail paste.
13:55:27 <regXboi> #info question is now how to access the members of the list in the value
13:55:43 <regXboi> #info devinavery thinks we should do type checking via instanceof
13:55:57 <regXboi> can we try it here?
13:56:59 <devinavery> We should be able to - should be quick. Neel - are you able to make the changes quickly to verify I am correct? According to eclipse you should be able to check / cast to Container Node
13:57:12 <Neel_B> one second
13:58:16 <devinavery> And then call "getValue()" which returns an iterator of children. See org.opendaylight.yangtools.yang.data.api.schema.DataContainerNode<K>
14:00:36 <Neel_B> its a raw data type
14:00:50 <Neel_B> what type to put in <k> ?
14:03:04 <devinavery> I would leave it as '?" for now.
14:03:15 <Neel_B> okay
14:03:37 <devinavery> Just print out the values again. Likely it will be ImmutableLeafNode, ImmutableLeafNode etc
14:04:04 <Neel_B> i compiling
14:04:13 <Neel_B> just a sec
14:05:27 <Neel_B> List of Leaf Nodes
14:05:35 <Neel_B> [ImmutableLeafNode{nodeIdentifier=(http://netconfcentral.org/ns/toaster?revision=2009-11-20)toasterStatus, value=up, attributes={}}, ImmutableLeafNode{nodeIdentifier=(http://netconfcentral.org/ns/toaster?revision=2009-11-20)toasterManufacturer, value=Opendaylight, attributes={}}, ImmutableLeafNode{nodeIdentifier=(http://netconfcentral.org/ns/toaster?revision=2009-11-20)toasterModelNumber, value=Model 1 - Binding Aware, attr
14:11:08 <devinavery> Ok. So now you can iterate those values doing a similar recursive check
14:16:36 <Neel_B> got it the child nodes
14:17:07 <Neel_B> Child node is :ImmutableLeafNode{nodeIdentifier=(http://netconfcentral.org/ns/toaster?revision=2009-11-20)toasterStatus, value=up, attributes={}} Child node is :ImmutableLeafNode{nodeIdentifier=(http://netconfcentral.org/ns/toaster?revision=2009-11-20)toasterManufacturer, value=Opendaylight, attributes={}} Child node is :ImmutableLeafNode{nodeIdentifier=(http://netconfcentral.org/ns/toaster?revision=2009-11-20)toasterModelN
14:17:22 <regXboi> that looks like we've got walking now
14:17:33 <regXboi> especially if we tie it back with recursion
14:17:33 <devinavery> regXboi: yup!
14:18:16 <devinavery> exactly. We can recursively check each value. I think the next steps are to do a loose mapping between the base node types the xpath interfaces.
14:19:25 <devinavery> We have a ContainerNode which contains children, and leafNodes which contain leaf values. Likely there is also a root for Lists which we can use to provide next sibling etc
14:21:04 <Neel_B> con you write the #actions ..
14:21:08 <Neel_B> can*
14:22:47 <devinavery> #info Neel found that we can use instance of to check the types of the values and convert them to ContainerNode, or LeafNode etc
14:23:15 <edwarnicke> devinavery: *So* happy to have you back :)
14:24:54 <devinavery> #action Next step is to wrap the NormalizedNode with the xpath interfaces to map the classes together.
14:27:44 <devinavery> #info for example a ContainerNode would map to children in the XPath interfaces. A ListNode would likely map to children / siblings and Leafs would map to Xpath Leafs etc. We should be able to map the two together now.
14:28:11 <Neel_B> ListNode ?
14:28:24 <Neel_B> the type is ImmutableLeafNode
14:29:17 <devinavery> Thats because the Toaster doesn't have a child list :) So we would need to mock up a list as well for testing purposes
14:30:06 <regXboi> wait
14:30:23 <devinavery> regXboi: yes?
14:30:30 <regXboi> if the Toaster had a child, wouldn't it also be a ContainerNode?
14:30:49 <regXboi> instead of a Leaf node?
14:30:58 <devinavery> If the Toaster had a child Container node, then yes
14:31:13 <regXboi> then we need an undo
14:31:13 <devinavery> My guess is that it would be a ContainerNode as well
14:31:21 <Neel_B> then any other app we have uses the child container ?
14:31:26 <regXboi> #undo
14:31:26 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x275bf50>
14:32:04 <regXboi> #info for example a ContainerNode would map to children in the XPath interfaces. A leaf node would map to Xpath Leafs.
14:32:31 <regXboi> #info there is an outstanding question about sibling relationships
14:32:47 <regXboi> I don't think we get sibling relationships
14:33:08 <regXboi> if we did, we would have gotten something other than ImmutableLeafNodes
14:33:36 <regXboi> #info regXboi is concerned we may have to build sibling information on the fly :-(
14:33:45 <devinavery> Sibling relationships are likely implied. All children of the toaster are siblings.
14:34:13 <regXboi> I think we should test that
14:34:15 <regXboi> :)
14:34:38 <regXboi> so I think the next step is to wrap the container and leaf nodes
14:34:42 <regXboi> and then see where we get
14:34:50 <regXboi> right?
14:35:07 * regXboi pads off for more caffeine
14:35:40 <devinavery> Yes. That sounds like correct next step. We will need to see how Lists play into this in a bit.
14:40:38 <regXboi> #action modify previous action: wrap the container and leaf nodes into Xpath and test to see if lists get handled correctly automagically
14:41:40 <regXboi> anything else?
14:41:55 * regXboi thinks we've made good progress
14:43:05 <Neel_B> wrapping in the sense ?
14:43:14 <Neel_B> now we have dataContainerNode
14:43:32 <Neel_B> we cast it into node/element ?
14:43:33 <devinavery> Not sure I understand your question Neel
14:45:03 <Neel_B> or just initialize xpath on DataContainerNode
14:45:04 <Neel_B> ?
14:48:45 <Neel_B> devinavery,regXboi
14:48:46 <Neel_B> ?
14:49:00 * regXboi thinking
14:49:09 <devinavery> I would create a new class which extends the xpath interfaces and takes the ContainerNode, LeafNode etc. And then delegate the calls to the xpath interface into the ContainerNodes etc
14:49:35 <devinavery> That is what I meant by "wrapping" the container nodes in the interfaces
14:50:10 <regXboi> yeah I think that's the best way forward
14:50:25 <regXboi> colindixon: notes are here
14:50:41 <regXboi> https://meetings.opendaylight.org/opendaylight-intern/2014/md_sal_query/opendaylight-intern-md_sal_query.2014-08-08-13.54.log.txt
14:50:45 <colindixon> regXboi: thanks
14:50:49 * colindixon looks
14:50:59 <colindixon> I don’t know what happened to this week
14:51:13 <regXboi> colindixon: before I forget - do you get the ACM communications?
14:51:44 <colindixon> not usually
14:51:47 <regXboi> or I should say _communications of ACM_
14:52:16 <regXboi> go find the 8/2014 issue - there is a *very* interesting research highlight paper
14:52:25 <regXboi> "quantifying eventual consistency with PBS"
14:52:57 <regXboi> PBS == probabilistically bounded staleness
14:53:33 <devinavery> Neel_B: Does the next steps make sense to you?
14:53:50 * regXboi aplogoies for hijacking... back to regularly scheduled meeting
14:55:12 <devinavery> regXboi: No worries - I need to step away - but wanted to make sure Neel was all set
14:55:18 <Neel_B> yeah
14:55:23 <Neel_B> i guess
14:55:49 <Neel_B> extend xpath interface to take container nodes instead of nodes
14:55:52 <Neel_B> right ?
14:56:12 <regXboi> I would say it differently
14:56:18 <devinavery> Yup. That is a good summary. I would suggest you take a quick stab and upload your code for Monday
14:56:32 <Neel_B> yeah
14:56:33 <regXboi> but if devinavery gets it I won't complain :)
14:56:34 <Neel_B> i would
14:56:46 <devinavery> regXboi: please - saying things multiple ways are good :)
14:57:00 <Neel_B> regXboi: your way please
14:57:22 <regXboi> I would have said it as create a new class that implements the xpath interface, takes the container node as part of the class constructor
14:57:46 <regXboi> and then the xpath interface methods are run against the container node that was passed in
14:57:53 <devinavery> regXboi: +1
14:59:26 <devinavery> Alright. I need to step away. Thanks all. Look forward to meeting Monday (same time I hope). Neel - if you get code updated before had please load it up and send an e-mail. We can pull it down and look at it
15:00:00 <Neel_B> yeah i will
15:00:06 <devinavery> Thanks
15:00:11 <regXboi> and ...
15:00:19 <Neel_B> code till now updated
15:00:27 <regXboi> #action regXboi to send email with minutes and next meeting
15:00:30 <regXboi> #endmeeting