13:36:34 <devinavery> #startmeeting jQuery/XPath for MD-SAL intern
13:36:34 <odl_meetbot> Meeting started Wed Aug 13 13:36:34 2014 UTC.  The chair is devinavery. Information about MeetBot at http://ci.openstack.org/meetbot.html.
13:36:34 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:36:34 <odl_meetbot> The meeting name has been set to 'jquery_xpath_for_md_sal_intern'
13:36:34 <odl_meetbot> devinavery: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
13:36:58 <devinavery> #info Neel_B uploaded new code for review.
13:37:50 <Neel_B> okay u said not to use class variables but i had to use some for children
13:37:59 <devinavery> Looking
13:38:21 <Neel_B> i am thinking of a setter method for children but i am out of ideas .. :\
13:38:29 <Neel_B> i mean sibling*
13:38:50 <devinavery> Ok. Let me get your source pulled in (eclipse is acting up for me right now)
13:39:39 <devinavery> #info Neel has some questions on how to implement siblings in the new normalized node.
13:40:08 <devinavery> #info Neel also commented that he had to use a local variable to hold the child nodes instead of calculating them on the fly
13:44:47 <Neel_B> devinavery:  got any comments ?
13:45:13 <devinavery> Sorry - still trying to get eclipse to let me run your test. I do have comments. Need a few minutes
13:47:11 <Neel_B> sure
13:49:32 <devinavery> Ok. So when I ran your tests the basic evaluates appear to be working. So likely that means we need some more complex XML to really test all of the functional
13:49:52 <devinavery> scratch that - I was using real XML. :)
13:53:16 <devinavery> Ok. WE could probably do some trickery with iterators to create the siblings on the fly. But the more I look at this I feel we should take it in iterations.
13:54:16 <devinavery> well... hold on. Still thinking here...
13:57:06 <devinavery> ok... I think I have an algorithm that will work...
13:57:11 <devinavery> It is going to be a little tricky.
13:57:19 <devinavery> Let me try to sudo code it up quickly.
13:57:24 <devinavery> psudo**
14:04:14 <devinavery> Ok Neel. Getting a paste bin set up with pseudo code.
14:05:02 <devinavery> http://pastebin.com/RaG1d5AA
14:06:01 <devinavery> Neel - please check out the paste bin code I posted above
14:06:28 <devinavery> #link http://pastebin.com/RaG1d5AA Quick psudo code showing possible way to handle "next sibling" on the fly
14:07:45 <devinavery> #info devinavery posted psudo code for algorithm which *might* work to calculate the next sibling on the fly (link above). The idea is that you pass the iterator along to each child as get next sibling is called, which allows it to construct the next sibling on the fly.
14:08:11 <devinavery> #info Would need some serious unit testing ( which we would need anyways) to verify this works as desired. But seems plausible to me
14:08:58 <devinavery> Neel_B: I am stepping away for 1 minute. Please review psudo code and see if that makes sense
14:09:10 <Neel_B> i am going through it
14:16:24 <devinavery> I am back
14:22:09 <Neel_B> devinavery: trying to implement just give me a few minutes
14:22:58 <devinavery> Neel_B: ok
14:31:29 <Neel_B> devinavery: in the second constructor
14:31:36 <Neel_B> the iterator type ?
14:34:30 <Neel_B> devinavery: ?
14:35:16 <devinavery> Sorry Neel - multi tasking
14:35:43 <devinavery> The iterator that is passed in there is the iterator which you get from the get Value()
14:38:20 <Neel_B> i kind of lost
14:39:49 <Neel_B> andcan you explain the sibling logic
14:45:56 <devinavery> Ok. So the idea here is then we want to create the children / siblings on the fly, instead of preprocessing it all.
14:47:16 <Neel_B> okay
14:47:47 <devinavery> So, I figured we can just pass the iterator that we use to get the first child for a given node.
14:47:47 <Neel_B> so the nextSibling should be iterator
14:48:23 <Neel_B> iterator.next() is the first node right ?
14:48:56 <Neel_B> the class variable nextSibling should be iterator  you mean to say?
14:49:17 <Neel_B> and not NodeBuilderElement
14:49:31 <devinavery> So with the iterator, you can only call next() once. Then when you construct the node you will want to cache it
14:51:14 <devinavery> So you will need to store the iterator AND the nextSibling variables
14:51:37 <devinavery> #info Neel_B is trying out - has some clarifying questions (see full text log for specific discussion)
14:52:18 <Neel_B> okay i got you now
14:52:59 <devinavery> Ok. Awesome. So. to recap, my approach was this: When a parent creates the first child, it passes the iterator to that child. The child then uses the iterator to calculate and create the sibling on the  fly
14:56:50 <Neel_B> when to change flags
14:56:59 <Neel_B> i my mind is dead :\
14:57:22 <Neel_B> devinavery: ?
14:57:25 <devinavery> When you change flags>?
14:57:39 <devinavery> (I only have about 3 minutes left Neel - just as aheads up)
14:59:18 <devinavery> Neel - I need to stop here. Play with this a little and see if you can get something working. Again the idea is that you keep passing the iterator to each sibling and that siblinging uses the iterator one time to calculate the next sibling on the fly
14:59:32 <devinavery> Are you free same time tomorrow for follow-up?
14:59:51 <Neel_B> yeah
15:00:01 <Neel_B> i have coded all you have told
15:00:41 <Neel_B> the class booleans first child init and sibling init
15:01:16 <devinavery> Ok. If you want to upload your code agai. I will review later today and send more comments via e-mail
15:01:22 <devinavery> I need to jump off now
15:01:27 <Neel_B> okay sure
15:01:35 <Neel_B> let me know through email thanks
15:02:34 <Neel_B> i guess i have done correctly notsure
15:02:45 <devinavery> #action Neel_B will attempt change and will upload code. Devinavery will review later and send e-mail to follow up
15:02:58 <Neel_B> one last thing
15:03:10 <devinavery> #action - devinavery send out notes and invite to next meeting on IRC - same time tomorrow
15:03:19 <devinavery> Yes? needs to be quick
15:03:21 <Neel_B> default next sibling would be null unless the iterator
15:03:34 <Neel_B> is specified in arguements
15:03:36 <Neel_B> right ?
15:03:54 <devinavery> Yes. I think that is correct
15:04:46 <Neel_B> okay thanks i am testing the code
15:04:57 <devinavery> #endmeeting