15:00:23 <colindixon> #startmeeting jQuery/XPath for MD-SAL intern
15:00:23 <odl_meetbot> Meeting started Wed Jul  2 15:00:23 2014 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
15:00:23 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:23 <odl_meetbot> The meeting name has been set to 'jquery_xpath_for_md_sal_intern'
15:00:28 <colindixon> #topic status update
15:00:54 <colindixon> #link https://github.com/neel1438/Opendaylight/ Neel_B has updated his repo
15:01:10 * regXboi looks
15:02:06 <regXboi> it looks like code to create the XML
15:02:25 <regXboi> how does this work against the the existing code
15:03:09 * regXboi goes and builds
15:03:21 <colindixon> #info the main change seems to be adding ConstructXml.java which builds a Node, but does so by making a document
15:03:30 <colindixon> we lost Neel
15:04:24 <regXboi> no worries
15:04:35 <regXboi> I'm verifying that this works
15:06:02 <colindixon> you need the test.xml
15:06:14 <colindixon> and you need to change the hard coded filename
15:06:39 <regXboi> yah
15:07:16 <regXboi> but it does work after those two changes
15:07:59 <regXboi> colindixon: link to previous meeting minutes?
15:08:05 * regXboi wants to review
15:08:10 <Neel_B> did i miss any thing some how my pidgin messenger  got disconnected
15:08:46 <regXboi> Neel_B: no... I was pulling the code and compiling it and colindixon was noting the delta from last time
15:08:50 <colindixon> regXboi: https://meetings.opendaylight.org/opendaylight-intern/2014/jquery_xpath_for_md_sal_intern/opendaylight-intern-jquery_xpath_for_md_sal_intern.2014-07-01-15.10.html
15:09:20 <colindixon> so, Neel_B, I’m not sure that I understand what’s going on because we’re not using the Node class anymore
15:09:45 <colindixon> which means we’re not learning what we’d need to do to get the MD-SAL nodes act like a Document
15:10:18 <regXboi> colindixon: why do you say that?
15:10:20 <regXboi> I see Node
15:10:32 <regXboi> what I don't see is MyNode and MyDocument
15:11:21 <colindixon> regXboi: so CreateXml.java uses a document builder/factory
15:11:25 <colindixon> right?
15:11:31 <Neel_B> yeah
15:11:47 <regXboi> you mean ConstructXml.java?
15:11:50 <colindixon> yes
15:12:20 <Neel_B> isn't that what you were expecting ?
15:13:06 <Neel_B> we can read values from MD-SAL every time  and construct this xml on the fly and call xpath
15:13:21 <Neel_B> this is what i understood and didaccordingly
15:13:33 <Neel_B> did accordingly*
15:13:39 <regXboi> ah I see
15:14:19 <colindixon> Neel_B: so, the hope was that we could build our own version of Node
15:14:31 <colindixon> and use that without having to use Document
15:14:41 <colindixon> because Node has fewer things to implement
15:15:25 <Neel_B> node is superclass of document i guess ?
15:15:39 <colindixon> yes
15:16:30 <colindixon> #info ConstructXml.java builds a Document (which is also a Node) that actually has the data in it
15:16:31 <devinavery> So I just looked at the code
15:17:00 <regXboi> devinavery: yes?
15:17:08 <Neel_B> there are somethings we are missing in hardcoding the nodes
15:17:08 <devinavery> For performance reasons, we will NOT be able to build a document out of the contents of the MD-SAL data store like you have done here
15:17:22 <regXboi> devinavery: agreed
15:17:38 <colindixon> Neel_B: so that would be useful discussion to have
15:17:40 <devinavery> We will have to wrap live MD-SAL objects and constructs with the interfaces that XPath needs (which is org.w3c.dom.Node)
15:17:58 <Neel_B> i have an alternative from the same construct Xml.java
15:18:04 <regXboi> devinavery: whoa...
15:18:06 <Neel_B> it should be like this
15:18:07 <devinavery> Thats why we want to understand what it takes implement a Node.
15:18:21 <Neel_B> i guess i understood a bit
15:18:35 <Neel_B> there is a document node which is the root
15:18:54 <Neel_B> which has element nodes as children
15:19:05 * colindixon looks
15:19:09 <devinavery> rexBoi: I am not 100% sure what we are wrapping yet, but we want to wrap MD-SAL in someway - that is my point.
15:19:23 <devinavery> regXboi: does that ease your concern any? :)
15:19:36 <Neel_B> and each element node has text node as children  which is b or c2 or c1 etc
15:19:55 <regXboi> devinavery: the whoa was I looked at what implementing Node implies
15:20:13 <Neel_B> also each element node has element nodes as chidren too
15:20:26 <Neel_B> did i make sene to any one ?
15:20:35 <devinavery> regXboi: ahh. :) Yes, though through this exercise so far it looks like we really only need to implement a half a dozen or so of the methods (i.e. a few read only methods)
15:21:12 <devinavery> Neel_B: yes that makes sense.
15:21:36 <colindixon> the current line of reasoning was as follows: (1) internally the MD-SAL uses nodes, lets call them MDNode, (2) internally a Document uses nodes, let’s call them w3cNode, (3) XPath queries take things that implement w3cNode and returns a list of children that match the query, (3) as a consequence if we figure out the effort to build a custom thing that implements the w3cNode interface and works for the XPath queries we ca
15:21:36 <colindixon> about we can start thinking about how to wrap the MDNode class with something to make the whole thing work
15:22:11 <colindixon> sorry for that blob of text
15:22:24 <devinavery> colindixon: agree.
15:22:42 <colindixon> so, Neel_B the issue is that eventually we are going to need to implement a class of our own (without using document) that provides the Node interface
15:22:55 <colindixon> and we want to understand what methods we need to implement to do that
15:23:18 <regXboi> so the point here is that we need to implement the methods of Node that Xpath uses, but *NOT* via Node so that we can see about grafting them on to MDNodes
15:23:26 <colindixon> yes
15:23:53 <colindixon> org.w3c.dom.Node is actually an interface
15:24:00 <colindixon> so we just need our own implementation of it
15:24:18 <colindixon> http://docs.oracle.com/javase/7/docs/api/org/w3c/dom/Node.html
15:24:32 <regXboi> do we need all of it, or just the "get" methods?
15:24:38 <colindixon> Neel_B: does what I said make sense?
15:24:56 <devinavery> regXboi: we only need *some* of the get methods. :)
15:25:09 <Neel_B> it did .... i am thinking how
15:25:13 <regXboi> no has/is methods?
15:25:26 <colindixon> regXboi: so, what we had done is to implement ThrowExceptionNode so we can tell quickly when we need to add new methods
15:25:34 <regXboi> ah
15:25:36 <regXboi> got it
15:25:54 <Neel_B> i guess all the functions i wrote are sufficient then
15:25:58 <colindixon> and then did custom extensions of that with hardcoded values in the TestXpath.java to figure out what we could get away with
15:26:27 <devinavery> Would it be useful to jump on a google hangout and write the "test" cases together?
15:26:55 <colindixon> yeah
15:27:00 <devinavery> Or even if I just jump on a hangout with Neel to do it with him. That way we can be clear on what the test cases are
15:27:00 <colindixon> that would probably make sense
15:27:21 <Neel_B> okay
15:27:24 <Neel_B> sure
15:27:24 <colindixon> public hangout or do you want me to start one?
15:27:33 <devinavery> we can go to the public hangout
15:27:39 <Neel_B> okay
15:27:47 <colindixon> http://hangout.vyatta.com/
15:59:38 <colindixon> #info Neel_B, devinavery, regXboi and colindixon gathered in a google hangout to jointly write JUnit test cases
16:07:43 <colindixon> #chair regXboi devinavery
16:07:43 <odl_meetbot> Current chairs: colindixon devinavery regXboi
16:07:52 <colindixon> you guys can do the #endmeeting
16:08:18 <devinavery> Thanks
17:25:49 <devinavery> #action Neel_B To upload junit test and code to his new git repo
17:26:03 <devinavery> #action Neel_B to then implement the hardcoded nodes to get existing JUnit tests passing
17:26:46 <devinavery> #action devinavery to download the JUnit code, and work with colindixon and regXboi to come up with more interesting "questions" we want to ask, so we can provide some more xpath statements to test with
17:27:12 <devinavery> #action devinavery will write the xpath exp and provide to Neel_B to test once his code is passing the existing JUnits
17:28:05 <devinavery> #info Next meeting by IRC is set for Monday July 7th, unless e-mails say otherwise. Same time - 11 Est / 10 Central / 8:30 India
17:28:25 <devinavery> #info Neel_B to send e-mails as he completes the various work.
17:28:44 <devinavery> #action Neel_B should send e-mails as he finishes work and upload changes to his git repo.
17:28:49 <devinavery> #endmeeting