13:10:59 <colindixon> #startmeeting ODL Intern Meeting (jQuery/XPath for MD-SAL)
13:10:59 <odl_meetbot> Meeting started Thu Jun 26 13:10:59 2014 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
13:10:59 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:10:59 <odl_meetbot> The meeting name has been set to 'odl_intern_meeting__jquery_xpath_for_md_sal_'
13:11:37 <colindixon> #info per devinavery’s suggestion, Neel_B has built a shim for the Document class to figure out what functions XPath queries actually use
13:12:13 <colindixon> #link https://github.com/neel1438/Opendaylight/ the code so far can be found here
13:12:52 <colindixon> #info it appears as though the query only uses functions found in org.w3c.dom.Node
13:13:11 <devinavery> hello hello
13:13:24 <colindixon> hey
13:13:28 <colindixon> just summarizing
13:13:34 <Neel_B> i started working on Node class too
13:13:45 <Neel_B> will be done by night!
13:13:53 <devinavery> Yup. I can see the history. Don't let me interrupt. :)
13:14:01 <devinavery> neel_b: awesome
13:14:08 <Neel_B> After that we might want to create our own instantiation of the Node interfaces which is set up to return the same XML, only lets hard code it in our logic. That way we can get an idea of how we might need to iterate over values etc when we go to the real system (MD-SAL).
13:14:38 <colindixon> Neel_B: that sounds good, so what are you implenting the Node class on top of?
13:14:42 <Neel_B> can you eloborate ?
13:14:47 <colindixon> (also this all sounds awesome)
13:14:58 <devinavery> neel_b: sure... here goes (typing)
13:15:47 <Neel_B> Same as Document interface i am implementing Node simlarly
13:15:58 <devinavery> Right now we let the XML parser create the instances of the Node class for us. But I was thinking it would be good to make sure that we understand anything that we might be missing from the Node logic. So, I was suggesting that we create our own implementation of the Node interface
13:15:59 <colindixon> Neel_B: ok
13:16:10 <Neel_B> public class MyNode implements Node{}
13:16:16 <colindixon> ah
13:16:17 <colindixon> got it
13:16:21 <colindixon> that makes sense
13:16:34 <devinavery> Then implement the methods that we know are called, with hardcoded values. For example, getFirstChildNode(), when called on "a" return a new "B" node etc
13:16:48 <colindixon> #action Neel_B is going to make a version of MyNode like the MyDocument just to make sure we understand what’s going on
13:17:26 <devinavery> Really just hack / hardcode (it can be ugly) implementations for the node class. Then pass our implementations into the path engine and make sure we get similar results (we don't have to go crazy, we can do a very simple XML document structure, even simpler then what we have today)
13:17:46 <colindixon> #info the XPath query will accept just a Node (rather than a Document), so that will likely be an easier path to implementation
13:17:52 <devinavery> That way we can really just prove that we can build and tie into xpath our own implementation of Node and not have things blow up
13:18:25 <devinavery> neel_b: does that help clarify a little? I can provide some pseudo code to help explain if needed
13:18:30 <Neel_B> why to hardcode node class ?
13:19:13 <colindixon> Neel_B: to avoid having to deal with the real system (the MD-SAL) until later on
13:19:14 <devinavery> It would just be another way to help ensure we understand how we might need to implement it. That said, if you feel like you have a good handle on that, we can skip it.
13:19:41 <Neel_B> provide me pseudo code as you said
13:19:53 <devinavery> Neel_B: give me a minute, will write it now
13:19:57 <Neel_B> sure sure
13:21:28 <Neel_B> what does hard coding accomplish actually ? we wouldn't get any thing new !(i may be thinking something else entirely)
13:23:35 <colindixon> #info after that, devinavery suggests implementing a version of Node that is hardcoded to return a fixed set of XML
13:23:47 <colindixon> #info (see full log for more details)
13:24:47 <colindixon> Neel_B: so, it’s just increasingly levels of real-ness
13:25:13 <colindixon> trying to give us stepping stones from implementing basically nothing (the current MyNode)
13:25:48 <devinavery> Just sent an e-mail with the pseudo code in it
13:26:16 <colindixon> to almost everything when we implement our own com.w3c.dom.Node interface on top of the MD-SAL’s code
13:26:59 <devinavery> Neel_B: hardcoding would give us an idea of how we might implement the node interface, so when we go to apply to MD-SAL we will have some idea. That said, I wouldn't spend more than an hour say on doing a hardcoded implementation. It should be fairly straight forward (and does NOT need to be pretty, efficient, or anything else)
13:28:04 <colindixon> +1 to that
13:29:02 <colindixon> Neel_B: the basic problem is this: when we move to the MD-SAL, we won’t have an XML document just laying around to read, we’re going to have to incrementally build parts of it as we go
13:29:16 <colindixon> and this explores that idea a bit without having to take on the full pain
13:29:57 <Neel_B> okay
13:30:04 <Neel_B> that made it clear
13:30:42 <Neel_B> we are building MD-sal/Nodes/xml not reading ?
13:30:48 <Neel_B> right ?
13:32:28 <Neel_B> okay
13:32:30 <devinavery> Neel_B: correct. We will build a Node that wraps MD-SAL's dom concept (NormalizedNode.java) or something like that. We still need to investigate there as well. By building our own implementation of Node now we can gain an understanding of the types of calls we need
13:33:04 <Neel_B> we use the MyNode class buld the Dom with it reading from MD-SAL
13:33:05 <Neel_B> ?
13:33:17 <Neel_B> if am  not wrong ?
13:33:30 <devinavery> For example, are we doing map look ups? Or just iterating lists (I think we are just iterating lists in the xpath implementation). This hardcoded implementation will tell us what we need to understand how to do on MD-SAL (i.e. do we need to do lookups in a map, or do we need the ability to iterate logical lists etc)
13:33:53 <devinavery> Correct Neel, in the long term, we would use an implement, like "myNode" to wrap MD-SAL core concepts
13:34:08 <Neel_B> cool that made it clear
13:34:19 <devinavery> that is, it would just be a layer that sits on top of MD-SAL, converting MD-SAL nodes to a standard node we can query
13:34:43 <Neel_B> directly using xpath
13:34:56 <Neel_B> sure got it
13:35:12 <colindixon> perfect
13:35:23 <colindixon> so, do we want to touch base this time tomorrow again to check in?
13:35:45 <Neel_B> node will be over mostly so
13:35:56 <Neel_B> node part*
13:36:15 <Neel_B> to wrap it on MD-SAL i will be needing help
13:36:38 <Neel_B> so i guess we should be meeting
13:37:30 <colindixon> ok
13:38:43 <Neel_B> so thats it for today ?
13:38:45 <devinavery> Neel_B: Have you created a provider application yet and deployed it to a running OSGI?
13:39:19 <Neel_B> nothing of that sort:\
13:39:45 <devinavery> Ok. I think we will need to insert a step in the middle there then. I will send an updated e-mail of what I think the "next" steps are after we get the hardcoded node implemented
13:40:06 <Neel_B> okay
13:40:36 <Neel_B> hey is saturday same time be fine instead of friday ?
13:42:20 <colindixon> Neel_B: maybe
13:42:27 <colindixon> when would be good for you
13:42:53 <colindixon> #info Neel_B will also have to get some practice bringing up a provider class in the MD-SAL, which should be another step
13:44:16 <Neel_B> any time on saturday
13:44:33 <Neel_B> like friday evening for you
13:45:50 <colindixon> Neel_B: yeah
13:46:28 <colindixon> when is too early for you on Saturday?
13:46:54 <devinavery> Not sure I will be able to state a specific time I can be online on Saturday (personally). But I can definitely make a point of checking e-mail a couple of times.
13:47:06 <devinavery> Don't let that stop you from meeting though if you want.
13:47:16 <colindixon> devinavery: noted
13:47:20 <Neel_B> okay no problem lets have it same time tomorrow
13:47:22 <Neel_B> no problem
13:47:28 <colindixon> Neel_B: sure
13:47:53 <colindixon> #info we’ll plan to meet again tomorrow at 8a centra/9a eastern/6:30p india unless we agree to something else via e-mail
13:48:09 <Neel_B> yeah sure done
13:48:27 <colindixon> #action devinavery to send out a slightly revised next steps plan including a step getting a simple MD-SAL provider up
13:48:40 <colindixon> Neel_B: I could meet Sunday night here, Monday morning for you
13:48:44 <colindixon> that would be a bit easier here
13:48:49 <colindixon> or were you planning to work over the weekend?
13:48:53 <devinavery> #info sent updated list of recommended next steps with pointer to the ping example. I think we can use the AbstractBindingAwareProvider, and the customer Rest API for prototyping MD-SAL interactions
13:49:20 <Neel_B> yeah
13:49:27 <colindixon> ok
13:49:36 <colindixon> so lets meet tomorrow at this time and we can keep the ball rolling
13:49:37 <Neel_B> i was planning to workover weekend but thats fine
13:50:16 <colindixon> as always, reach out over e-mail or IRC to give updates and/or ask for help
13:50:28 <Neel_B> yeah that i would do
13:50:28 <colindixon> thanks devinavery for keeping this stuff moving so smoothly
13:50:38 <colindixon> anything else you need Neel_B?
13:51:02 <devinavery> colindixon - no problem. I'd probably be doing it myself if Neel wasn't here... :P
13:51:27 <Neel_B> devin
13:51:45 <Neel_B> you haven't send any mail
13:51:47 <Neel_B> ?
13:52:18 <Neel_B> sorry got
13:52:19 <Neel_B> it
13:54:20 <colindixon> #endmeeting