13:30:45 <colindixon> #startmeeting jQuery/XPath for MD-SAL intern
13:30:45 <odl_meetbot> Meeting started Mon Aug 11 13:30:45 2014 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
13:30:45 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:30:45 <odl_meetbot> The meeting name has been set to 'jquery_xpath_for_md_sal_intern'
13:30:50 <colindixon> #topic status update
13:31:30 * colindixon goes off to read the minutes from last time
13:31:40 <colindixon> Neel_B: feel free to tell us where you are and what’s going on
13:32:47 <Neel_B> latest code updated
13:32:50 <Neel_B> not yet complete
13:33:11 <Neel_B> i have been in a discussion with devinavery  ..
13:33:27 <Neel_B> if you see the code you might get what we were planning to do
13:33:48 <colindixon> yeah, I’m reading the notes now
13:34:06 <colindixon> #link https://github.com/neel1438/Opendaylight/ latest code is here
13:35:27 <regXboi> sorry for being late
13:35:32 <colindixon> no worries
13:35:43 <regXboi> thanks for the slide deck reference
13:35:51 <regXboi> current log link?
13:35:54 <regXboi> (so I can catch up)
13:35:58 <colindixon> https://meetings.opendaylight.org/opendaylight-intern/2014/jquery_xpath_for_md_sal_intern/opendaylight-intern-jquery_xpath_for_md_sal_intern.2014-08-11-13.30.log.txt
13:36:02 <colindixon> the very short logs so far
13:36:50 * regXboi pulls code
13:38:36 <colindixon> #info colindixon will be on paternity leave from 8/15 to 9/1 (so my last day will be 8/14 and I’ll be back on 9/2)
13:40:13 <regXboi> so... I'm a bit confused by this
13:40:17 <devinavery> Hi Folks.
13:40:34 <colindixon> hey devinavery
13:40:49 <colindixon> regXboi and I are just skimming the most recent code
13:41:17 <devinavery> So I worked with Neel this morning a little bit
13:42:19 <regXboi> well, the structure from the git updates looks a little odd to me
13:43:09 <regXboi> I was sort of expecting that (worst case) we'd create an element from each normalized node and build the children tree ourselves on the fly
13:43:13 <devinavery> I explained that we wanted to take what we did a few weeks back. Neel was just starting to pull in some of those pieces
13:43:14 <regXboi> I don't see that in there
13:43:49 <devinavery> I am looking at the new code myself. One minutes
13:45:22 <Neel_B> did i do some thing else completely ?
13:45:57 <devinavery> Ok. So you just copied the code for right now
13:47:03 <Neel_B> yeah and i am trying to build
13:47:07 <colindixon> #info the new patch has an empty NewElement class which is just stubs for the interface Element and NodeBuilderElement which appears to be the start of something that we could wrap around a NormalizedNode
13:47:12 <devinavery> I think what you want to do is modify the NodeBuilderElement class , remove all class variables, and instead delegate the calls to a Normalized node that you passed in
13:47:22 <colindixon> +1
13:47:47 <Neel_B> i was doing the same in toaster.test
13:48:31 <devinavery> Neel_B: That is the what I was talking about. I would modify the NodeBuilderELement copy that you have in the heel-toaster-it code
13:49:06 <devinavery> neel-toaster-it***
13:49:14 <Neel_B> i didn't get you
13:49:38 <Neel_B> i have nodeBuilder
13:49:51 <colindixon> so, right now NodeBuilder is backed by some variables
13:50:01 <colindixon> boolean hasChildren;
13:50:01 <colindixon> String nodeName;
13:50:03 <colindixon> Node parent;
13:50:04 <colindixon> Node nextSibling;
13:50:06 <colindixon> Node firstChild;
13:50:06 <Neel_B> you mean to say take NormalizedNode as some arguement to constructor
13:50:07 <colindixon> Node lastChild;
13:50:09 <colindixon> String textContent;
13:50:10 <colindixon> Node[] children;
13:50:12 <colindixon> so, whenever, you get a call, you look up the answer based on those variables
13:50:15 <colindixon> Neel_B: yes
13:50:22 <Neel_B> and then do according ly
13:50:25 <Neel_B> right
13:50:30 <colindixon> the idea would be to replace all of those variables with a single NormalizedNode
13:50:47 <Neel_B> i got it
13:50:48 <colindixon> and then figure out how to map the calls onto that single varialbe
13:51:04 <devinavery> * Stepping away for a minute
13:51:13 <Neel_B> some basic things
13:51:24 <colindixon> that’s what devinavery means by “delegate the calls to a NormalizedNode that you passed in"
13:51:50 <Neel_B> normalized node name and textContent ?
13:52:03 <Neel_B> how do i get that
13:52:47 <colindixon> normalized nodes hould have a name I’m pretty sure
13:52:49 * colindixon looks
13:53:10 <regXboi> shouldn't name == identifier as a first pass?
13:53:29 <regXboi> and I expect textContent to be empty for anything other than a leaf node
13:53:46 <regXboi> and for a leaf node, textContent is then the getValue
13:53:53 <Neel_B> okay DataContainerChild is the leaf Node
13:54:02 <Neel_B> one more thing
13:54:20 <regXboi> DataContainerChild *can be* a leaf node, but may not be
13:54:56 <colindixon> regXboi: I’d agree with all of that
13:55:06 <devinavery> +1
13:55:12 <Neel_B> so i have to wrap DataContainerChild also
13:56:08 <regXboi> devinavery: isn't datacontainerchild a subclass of datacontainernode?
13:56:21 <regXboi> er DataContainerChild and DataContainerNode
13:56:38 <colindixon> #topic next steps
13:57:17 <colindixon> #action Neel_B should rework NodeBuilderElement to instead be backed by a single NormalizedNode, which is passed in via the constructor
13:57:44 <colindixon> did we figure out what K and V were?
13:57:48 <devinavery> DataContainerChild and DataContainerNode are not int he same hierarchy . However, ContainerNode implements both. Which means in a way they are tied together
13:58:04 <colindixon> I’m 99% sure that K is an instance identifier
13:58:46 <devinavery> colindixon: yes. You are correct
13:58:58 <devinavery> Actually, it would be a YangInstanceIdnetifier (we renamed them)
13:59:24 <colindixon> and I’m guessing V is one of a set of morphs of node, e.g., list node, etc.
13:59:53 <devinavery> I think I follow and agree
14:00:41 <colindixon> so, Neel_B was asking what he should do for nodeNode and textContent
14:00:42 * regXboi not sure he follows 100% but that's ok
14:01:30 <colindixon> I think the answer is that nodeName should really be somthing like normalizedNode.getValue().getClass().getName()
14:01:53 <regXboi> is that going to be unique?
14:01:56 <Neel_B> .getValue is an iterator ?
14:02:32 <Neel_B> iterator.getclass().getName ()?
14:02:56 <colindixon> #link https://gist.github.com/nilok/0fd811199aa4d71d3c14 this is NormalizedNode
14:03:29 <regXboi> so, correct me if I'm mistaken, but shouldn't nodeName be unique?
14:03:40 <colindixon> if we’re honoring the idea of an w3c.dom.Element, isn’t the name the tag?
14:03:45 <devinavery> NodeName should be unique....
14:03:49 <colindixon> which isn’t necessarily unique?
14:03:56 <colindixon> maybe I’m wrong
14:04:01 <devinavery> well... actually doesn't have to be fully unique
14:04:09 <devinavery> But the name is what ties to the path
14:04:19 <devinavery> that is :     /path1/path2/path3
14:04:47 <regXboi> oh
14:05:04 <devinavery> In this xpath path1 would be node 1, path2 would be the name for the child node etc
14:05:05 <regXboi> well then, should it be the nodeType?
14:05:12 <devinavery> That is my understanding.
14:05:43 <colindixon> so, I think taht for now, Neel_B I think they key is to get *something* working first and we can figure out how to tweak it to be “right” later
14:06:02 <Neel_B> java.util.Collections$UnmodifiableCollection$1
14:06:18 <Neel_B> this is the output of what you said colindixon
14:06:22 <regXboi> that doesn't look right
14:06:23 <colindixon> starting with getIdentifier().toString() for getNodeName() would likely be better
14:06:38 <colindixon> Neel_B: yeah, I think I was wrong then :-/ (see the recent discussion)
14:06:38 <regXboi> colindixon: +1
14:06:40 <colindixon> sorry
14:08:02 <Neel_B> for TextContent ?
14:08:33 <Neel_B> should i put some fixed textvalue and take care of it later ?
14:08:59 <regXboi> I'd say if getValue is an iterator, set it to null
14:09:10 <regXboi> and if getValue isn't, set it to getValue().toString()
14:09:16 <devinavery> For the identifier, I think colindixon is right, except just note that the child instance identifier will contain the parent instance identifier. So we will have more to do there to remove the duplicates, but that will be some we can do later
14:09:17 <regXboi> and see what we get
14:10:03 <devinavery> +1 to regXboi's suggestion
14:10:11 <colindixon> #info we’re not 100% sure what to return for getNodeName(), but for now using NormalizedNode’s getIdentifier().toString() [later, we’ll trim it to be more readable]
14:10:57 <colindixon> #info for textContent, regXboi says “if getValue() is an iterator, set it to null, otherwise set it to getValue().toString”
14:11:17 <Neel_B> it is an iterator
14:11:30 <colindixon> Neel_B: it wil sometimes be an iterator and sometimes not
14:11:53 <colindixon> #topic dealing with children/siblings
14:12:00 <colindixon> this is going to be the more complicated part
14:12:26 <regXboi> oh... this is going to be ugly
14:12:29 <colindixon> which is how to populate children and siblings based on the NormalizedNode
14:12:48 <colindixon> my gut reaction is to ignore siblings for now (hopefully that won’t bite us too soon)
14:13:00 <regXboi> colindixon: it will nail you almost immediately
14:13:05 <colindixon> ugh
14:13:21 <Neel_B> i am following
14:13:34 <colindixon> so, for children, the general idea is that if getValue() is an iterator, the things it iterates though are your children
14:13:49 <Neel_B> yes
14:13:50 <devinavery> Siblings should just be the iterator in the node
14:14:11 <regXboi> so... I think we are going to have to put a little bit more in that just NormalizedNode :/
14:14:19 <Neel_B> iterator.next() will be next sibling
14:14:41 <colindixon> devinavery: so you need to set up the siblings for your chidren as you build them, right?
14:14:48 <regXboi> unless we take apart the getIdentifier to figure out the parent
14:15:17 <devinavery> regXboi: ok... i think I am thinking of it wrong... one moment.../ :)
14:15:40 <colindixon> so, my understanding is the folllowing (which could be wrong)
14:15:59 <regXboi> devinavery: sure - I'm making the very conservative assumption that NormalizedNode doesn't have things like getParent or getSiblings
14:16:05 <devinavery> regXboi: ok, I follow you now. Yes, Siblings will be a little bit harder. :)
14:16:21 <regXboi> so if I'm at child node #1
14:16:38 <regXboi> the only way to get siblings is to go up to parent, getChildren, and remove me
14:16:39 <colindixon> (1) if the current NormalizedNode returns a list (iterator/iterable) for it’s getValue(), the things it iterates through are it’s children
14:17:05 <regXboi> colindixon: so far so good
14:17:20 <colindixon> (2) as you go through and build the children, you can populate *their* siblings by essentailly moving one more sibling along
14:17:38 <regXboi> yeah, that's what I was trying to avoid
14:18:04 <colindixon> regXboi: I don’t see any way to avoid it
14:18:10 <regXboi> well,, let's try this
14:18:19 <colindixon> Neel_B: did (2) make sense to you?
14:18:47 <Neel_B> nope
14:19:16 <regXboi> (A) - getChildren takes the getValues(), translates each element to NormalizedNode and then returns a list of our nodes where each element of the return list wraps a normalizednode
14:19:22 <regXboi> does that make sense to folks?
14:19:56 <colindixon> regXboi: yes
14:20:15 <regXboi> (B) - getSiblings take the name, extracts the parent from it, gets the parent, calls getChildren on the parent and then does an identity check on the returned list to remove self and returns the result
14:20:30 <regXboi> yes, B is hideous
14:20:33 <colindixon> regXboi: there is no getSiblings
14:20:34 <regXboi> but it *should* work
14:20:43 <colindixon> it’s only getNextSibling()
14:20:47 <regXboi> ah ok
14:20:52 <regXboi> let me change B then
14:20:58 <Neel_B> i am lost after a
14:21:03 <Neel_B> "A"
14:21:11 <regXboi> Neel_B: let me try B again
14:21:14 <regXboi> because I had it wrong
14:21:26 <regXboi> (B) - getNextSibling has to return the next sibling of a child
14:21:36 <regXboi> assuming that we don't build that into the structure, we have to get it live
14:21:46 <regXboi> which means we have to get the parent of the child
14:21:51 <regXboi> get the children of the parent
14:21:56 <regXboi> find self in the list of children
14:22:03 <regXboi> and return the next element in the children list
14:22:10 <regXboi> did *that* make sense to all
14:22:18 <Neel_B> teag'
14:22:22 <Neel_B> omg sorry
14:22:23 <Neel_B> yeah
14:22:56 <regXboi> now... I'm thinking after typing all of that, that it may just be easier to build that in as part of get children (since we are already doing some translation/casts)
14:25:02 * regXboi now wonders if I've confused everybody :)
14:25:44 <colindixon> what regXboi is saying is something like this: https://gist.github.com/nilok/a994e4984d9842483ddf
14:26:33 <regXboi> colindixon: +1
14:26:38 <colindixon> that involves adding a getChildren() method to NodeBuilderElement
14:26:56 <regXboi> we need that anyway, don't we?
14:27:03 <regXboi> er wait
14:27:06 <colindixon> it’s not part of ELement
14:27:06 <Neel_B> okay that makes sense
14:27:17 <colindixon> Element actually uses getFirstChild() and then getNextSibling()
14:27:18 <colindixon> :p
14:27:28 <regXboi> um
14:27:29 <regXboi> ok
14:27:31 <colindixon> but that woudl cause a recursive definition
14:27:34 <colindixon> which is bad
14:27:35 <regXboi> so in *THAT* case
14:27:42 <regXboi> I'd argue (very strenuously)
14:27:59 <regXboi> for building in firstChild and nextSibling into the wrapper
14:28:06 <regXboi> just to make things more optimal
14:28:13 <colindixon> :p more optimal
14:28:54 <regXboi> colindixon: I quote "remove coordination" :P
14:29:02 <colindixon> so, Neel_B, this is what regXboi is suggesting as an alternative, which I think might be cleaner
14:29:38 <Neel_B> not clear sorry
14:29:46 <colindixon> Neel_B: hold on
14:29:49 <colindixon> maybe we should wait on this
14:30:55 <colindixon> the basic idea is that when somebody calls getFirstChild() you want to get the first of your children and populate it with it’s nextSibling() already
14:30:57 <colindixon> which is easy for that case
14:31:24 <colindixon> the problem comes in when somebody does getFirstChild().getNextSibling().getNextSibling()
14:31:25 <Neel_B> okay
14:31:31 <Neel_B> it works for fist time
14:31:42 <Neel_B> the next time ?
14:31:53 <Neel_B> yeah exactly
14:31:53 <devinavery> Folks, I think we should take an iterative approach here.
14:31:57 <colindixon> which means that to lazily do it, you’d need to pass an iterator to the children
14:32:04 <devinavery> Lets come up with a simple xpath query, write a test for it, and just try and solve that
14:32:04 <colindixon> devinavery: that’s what I was about to say
14:32:18 <devinavery> That will give us an idea of what it is going to take, and then we can move forward from there
14:32:26 <devinavery> For now, lets just write a really simple xpath statement on toaster
14:32:29 <Neel_B> that makes things less messier
14:32:39 <devinavery> Even that is going to give us problems. :)
14:33:29 <colindixon> #info there was a lot of discussion about how to build children/siblings, but for now devinavery returns us to sanity and says let’s just focus on toaster
14:33:43 <colindixon> #topic next meeting and expectations
14:34:18 <colindixon> #info I think that the expectations is that Neel will have the new Element that uses the NormalizedNode to back it
14:34:22 <colindixon> do we want to meet tomorrow?
14:34:46 <devinavery> I think that is a good idea
14:34:53 <colindixon> #info and will have tested that with some really simple XPath query to see if it fails
14:35:04 <Neel_B> yeah
14:35:07 <colindixon> does this time slot tomorrow work for people
14:35:13 <Neel_B> some time late
14:35:19 <Neel_B> 9:30PM
14:35:23 <Neel_B> here ?
14:35:53 <colindixon> #info ideally, Neel_B would debug any failures and try to fix them, but if he can’t, we’ll help based on what we’ve learned
14:35:59 <colindixon> Neel_B: you mean later tonight?
14:36:01 <colindixon> we’ll be around
14:36:40 <Neel_B> tomorrow
14:36:59 <Neel_B> today is also fine
14:37:00 <colindixon> so, you’d rather meeting at 9:30p india time
14:37:10 <Neel_B> 7 is fine but
14:37:18 <Neel_B> i have my classes started
14:37:24 <colindixon> ah
14:37:27 <colindixon> so, this time: http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=8&day=12&hour=16&min=0&sec=0&p1=43&p2=24&p3=505
14:37:32 <Neel_B> so i might have some work regarding it
14:37:37 <colindixon> sure
14:38:06 <colindixon> that time is actually right on top of a meeting that devinavery and I have
14:38:16 <regXboi> I really can't make that time either
14:38:16 <devinavery> Was just going to say that
14:38:27 <Neel_B> if i don't have
14:38:27 <colindixon> would 8:30p or 10:30p work for you Neel_B ?
14:38:43 <Neel_B> let's make the meeting at same time
14:38:53 <regXboi> colindixon: tomorrow morning is a mess for me :/
14:39:03 <Neel_B> if i didn't show up assume  8:30 Pm
14:39:16 <Neel_B> is that fine ?
14:39:39 <colindixon> we could just do 8:30 if that’s better?
14:39:56 <Neel_B> okay 8:30 is fine by me
14:39:56 <Neel_B> :)
14:40:39 <colindixon> #link http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=8&day=12&hour=15&min=0&sec=0&p1=43&p2=24&p3=505&iv=1800 we’ll plan on having the next meeting at this time (10a central, 11a eastern, 8:30p india)
14:40:58 <colindixon> devinavery and I will have hard stop at a little bit more than an hour
14:41:05 <colindixon> but it will be be good to touch base
14:41:08 <colindixon> #endmeeting