fluid-work IRC Logs-2010-03-29
[15:23:03 EDT(-0400)] <michelled1> jhung: ok, try updating again <Bosmon8> But on the other hand, writing something like refreshView: " .render.refreshView" might be more idiomatic <Bosmon8> Or refreshView: might be better <colinclark> foo: or something?
[15:23:16 EDT(-0400)] <michelled1> tmbdev: are you there?
[15:24:28 EDT(-0400)] <jhung> michelled1: it's looking fine now.
[15:26:03 EDT(-0400)] <michelled1> so the rotate flag for decapod-stitching does in fact to something but I'm not quite sure how to use it
[15:26:22 EDT(-0400)] <michelled1> I'll have to check in with Thomas at some point
[15:28:02 EDT(-0400)] <michelled1> jhung: anything you want me to work on in particular or should I continue my hand off documentation?
[15:28:35 EDT(-0400)] <jhung> michelled1: I can really use help with writing up the test cases.
[15:28:53 EDT(-0400)] <michelled1> wanna skype real quick?
[15:29:02 EDT(-0400)] <jhung> Sure
[16:05:15 EDT(-0400)] <athena> is it possible to use the fluid renderer and the inline editor together?
[16:05:39 EDT(-0400)] <athena> my initial tests seem to indicate that it's all ok until you re-render the data, at which point weirdness begins to occur
[16:55:51 EDT(-0400)] * michelled1 (~decapod@ultraone.atrc.utoronto.ca) has left #fluid-work
[17:24:23 EDT(-0400)] * clown (~clown@142.150.154.202) has left #fluid-work
[17:24:57 EDT(-0400)] * clown (~clown@142.150.154.202) has joined #fluid-work
[23:16:17 EDT(-0400)] * yura (~yura@206-248-159-13.dsl.teksavvy.com) has joined #fluid-work
[00:57:25 EDT(-0400)] * tmb (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has left #fluid-work
[01:30:17 EDT(-0400)] * tmb (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[01:30:41 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[03:10:51 EDT(-0400)] * tmb (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[03:11:36 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[03:44:48 EDT(-0400)] * tmb (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[04:00:01 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[05:42:58 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[05:43:23 EDT(-0400)] * tmb (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[06:02:04 EDT(-0400)] * thomas_ (~thomasain@ingserv.demon.co.uk) has joined #fluid-work
[06:11:32 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[06:32:50 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[07:13:39 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[07:23:27 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[07:53:07 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[08:19:26 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[08:24:41 EDT(-0400)] * JASIGLogBot (~PircBot@jasig.Princeton.EDU) has joined #fluid-work
[08:24:41 EDT(-0400)] * Topic is 'This channel is logged – for details see: http://wiki.fluidproject.org/display/fluid/IRC+Channel' set by jessm on 2009-11-04 08:30:00 EST(-0500)
[09:03:16 EDT(-0400)] * JASIGLogBot (~PircBot@jasig.Princeton.EDU) has joined #fluid-work
[09:03:16 EDT(-0400)] * Topic is 'This channel is logged – for details see: http://wiki.fluidproject.org/display/fluid/IRC+Channel' set by jessm on 2009-11-04 08:30:00 EST(-0500)
[09:15:14 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[09:44:51 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[10:03:27 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[11:24:51 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[11:40:20 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[11:53:27 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[12:41:39 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[12:48:32 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[14:58:37 EDT(-0400)] * EricDalquist (~apollo@76.210.71.208) has joined #fluid-work
[15:02:15 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[15:25:18 EDT(-0400)] * EricDalquist (~apollo@76.210.71.208) has left #fluid-work
[21:36:42 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[21:56:35 EDT(-0400)] * sgithens (~sgithens@cpe-65-189-226-29.indy.res.rr.com) has joined #fluid-work
[04:56:21 EDT(-0400)] * thomas___ (~thomasain@ingserv.demon.co.uk) has joined #fluid-work
[07:28:57 EDT(-0400)] * thomas___ (~thomasain@ingserv.demon.co.uk) has joined #fluid-work
[10:37:29 EDT(-0400)] * thomas___ (~thomasain@ingserv.demon.co.uk) has joined #fluid-work
[12:44:56 EDT(-0400)] * greggy (~greg@142.150.154.79) has joined #fluid-work
[12:44:56 EDT(-0400)] * jamon (jamon@mantis.openject.com) has joined #fluid-work
[13:22:16 EDT(-0400)] * thomas___ (~thomasain@ingserv.demon.co.uk) has joined #fluid-work
[13:30:53 EDT(-0400)] * jamon_ (jamon@mantis.openject.com) has joined #fluid-work
[17:52:41 EDT(-0400)] * yura (~yura@206-248-159-13.dsl.teksavvy.com) has joined #fluid-work
[20:41:13 EDT(-0400)] * yura (~yura@206-248-159-13.dsl.teksavvy.com) has joined #fluid-work
[23:46:22 EDT(-0400)] * yura (~yura@206-248-159-13.dsl.teksavvy.com) has joined #fluid-work
[02:29:57 EDT(-0400)] * greggy (~greg@142.150.154.79) has joined #fluid-work
[03:51:48 EDT(-0400)] * thomas____ (~thomasain@213.246.129.247) has joined #fluid-work
[06:55:35 EDT(-0400)] * denbuzze (~anonymous@ginger.caret.cam.ac.uk) has joined #fluid-work
[08:21:34 EDT(-0400)] * jameswy (~jameswy@142.150.154.196) has joined #fluid-work
[08:33:00 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[09:17:24 EDT(-0400)] * jhung (~decapod@142.150.154.125) has joined #fluid-work
[09:21:44 EDT(-0400)] * athena (~athena@adsl-99-89-93-113.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[09:35:34 EDT(-0400)] * jessm (~Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined #fluid-work
[09:50:06 EDT(-0400)] * EricDalquist (~apollo@76.210.71.208) has joined #fluid-work
[09:55:12 EDT(-0400)] * clown (~clown@142.150.154.202) has joined #fluid-work
[10:01:17 EDT(-0400)] <jessm> jamon: the Ideum quote from jameswy – can that go into Alfresco?
[10:01:38 EDT(-0400)] * EricDalquist (~apollo@76.210.71.208) has left #fluid-work
[10:01:40 EDT(-0400)] <jamon> jessm: yep
[10:01:48 EDT(-0400)] <jessm> cool
[10:19:38 EDT(-0400)] * sgithens (~sgithens@149-166-9-57.dhcp-in.iupui.edu) has joined #fluid-work
[10:23:08 EDT(-0400)] <jessm> jhung: ping?
[10:23:37 EDT(-0400)] <jhung> jessm: yup.
[10:24:02 EDT(-0400)] <jessm> jhung: where are we this a.m. wrt Decapod and should we chat?
[10:24:19 EDT(-0400)] <jhung> I
[10:24:31 EDT(-0400)] <jhung> Yes. I think we should chat quickly.
[10:24:37 EDT(-0400)] <jhung> let me grab a headset.
[10:35:31 EDT(-0400)] * colinclark (~colin@142.150.154.101) has joined #fluid-work
[10:42:15 EDT(-0400)] <jessm> colinclark: welcome back!
[10:42:20 EDT(-0400)] <colinclark> 
[10:42:23 EDT(-0400)] <colinclark> thanks, boss
[10:50:57 EDT(-0400)] <colinclark> Hey, has anyone else noticed that we haven't been getting 24-hr updates from our wiki?
[10:51:05 EDT(-0400)] <colinclark> Seems like it's been quite awhile since I've seen one.
[10:52:12 EDT(-0400)] * michelled (~michelled@142.150.154.101) has joined #fluid-work
[10:55:00 EDT(-0400)] <jhung> The updates have been broken since Mar 3rd it seems. The Wiki front page hasn't updated since then.
[10:58:31 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[10:58:54 EDT(-0400)] <thomas____> I dived into the Infusion source at the weekend ... it blew my mind, I'll need to read more on the wiki
[10:59:56 EDT(-0400)] <thomas____> I like the work that's gone into incorporating aria
[11:00:43 EDT(-0400)] <thomas____> especially as part of the reorderer
[11:05:56 EDT(-0400)] <colinclark> thomas____: Glad you like it
[11:22:07 EDT(-0400)] * Bosmon7 (~a@cpc2-nmal2-0-0-cust681.croy.cable.virginmedia.com) has joined #fluid-work
[11:22:20 EDT(-0400)] <Bosmon7> Hi
[11:22:22 EDT(-0400)] <Bosmon7> I am here now
[11:22:37 EDT(-0400)] <Bosmon7> If we are due to start talking over the jQuery upgrade issues - colinclark, justin_o
[11:23:59 EDT(-0400)] <colinclark> Bosmon7: Stand up is in seven minutes
[11:24:13 EDT(-0400)] <colinclark> Is it something we can tackle in that time?
[11:24:36 EDT(-0400)] <justin_o> If anyone is interested... there is a jira pertaining to this FLUID-3527 and a branch by the same name
[11:24:37 EDT(-0400)] <jamon> i can restart the wiki if no one is using it at the moment for email updates? colinclark?
[11:25:18 EDT(-0400)] <justin_o> http://issues.fluidproject.org/browse/FLUID-3527
[11:25:24 EDT(-0400)] <justin_o> https://source.fluidproject.org/svn/fluid/infusion/branches/FLUID-3527/
[11:25:32 EDT(-0400)] <colinclark> jamon: Maybe best at the end of day, just to be safe?
[11:25:38 EDT(-0400)] <colinclark> I imagine people are busy with it at the moment
[11:25:57 EDT(-0400)] <jamon> k
[11:28:40 EDT(-0400)] <Bosmon7> Wow.... these timezone changes are just wacky 
[11:42:09 EDT(-0400)] <jessm> Bosmon7: why couldn't it all happen on the same day?!
[11:43:41 EDT(-0400)] <michelled> justin_o: can I get you to take a quick peek at this? http://wiki.fluidproject.org/display/fluid/Decapod+0.3+Test+-+Capturing+Images
[11:50:05 EDT(-0400)] * yura (~yura@142.150.154.101) has joined #fluid-work
[11:56:45 EDT(-0400)] <Bosmon7> jessm: No, I meant my timezone changes
[11:56:53 EDT(-0400)] <Bosmon7> Having standup at the end of the day is just puzzling....
[11:58:02 EDT(-0400)] <jessm> ah
[12:26:15 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[12:35:13 EDT(-0400)] * Bosmon8 (~a@cpc2-nmal2-0-0-cust681.croy.cable.virginmedia.com) has joined #fluid-work
[12:35:41 EDT(-0400)] * EricDalquist (~apollo@adsl-76-208-69-152.dsl.mdsnwi.sbcglobal.net) has joined #fluid-work
[12:42:15 EDT(-0400)] <justin_o> Bosmon8: how should we should we look into the jquery upgrade for engage
[12:44:10 EDT(-0400)] * EricDalquist (~apollo@adsl-76-208-69-152.dsl.mdsnwi.sbcglobal.net) has left #fluid-work
[12:44:35 EDT(-0400)] <Bosmon8> I think we can be relatively confident there will be no major issues
[12:45:02 EDT(-0400)] <Bosmon8> The problems in infusion were generally deep in framework code, where they should be
[12:53:12 EDT(-0400)] <justin_o> Bosmon8: that's good.. so you think we should just merge and then fix any problems that appear
[12:53:38 EDT(-0400)] <justin_o> i suppose for sure the my collection page will brake because of the use of the jquery dialog
[13:11:36 EDT(-0400)] * alisonbenjamin (~alisonben@dsl-173-206-255-118.tor.primus.ca) has joined #fluid-work
[13:12:49 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[13:15:38 EDT(-0400)] <alisonbenjamin> justin_o: hi
[13:15:49 EDT(-0400)] <justin_o> hello
[13:21:43 EDT(-0400)] <justin_o> alisonbenjamin: ^
[13:23:13 EDT(-0400)] <alisonbenjamin> justin_o: hey. I'm knocking "incorporate WCAG into QA test plan" jiras off my list. I was hoping we could touch base tomorrow? & look at what I've done
[13:24:09 EDT(-0400)] <justin_o> alisonbenjamin: sure
[13:24:11 EDT(-0400)] <justin_o> sounds good
[13:24:42 EDT(-0400)] <alisonbenjamin> justin_o: is there a time that works for you?
[13:24:58 EDT(-0400)] <justin_o> alisonbenjamin: hmm... not sure...
[13:25:29 EDT(-0400)] <justin_o> i don't have any meetings or anything planned yet, so i guess anytime should be okay
[13:35:35 EDT(-0400)] <alisonbenjamin> justin_o: thanks
[13:36:13 EDT(-0400)] <alisonbenjamin> justin_o: i will be there in the afternoon. would 2 work?
[13:36:28 EDT(-0400)] <justin_o> alisonbenjamin: should be okay
[13:37:03 EDT(-0400)] <alisonbenjamin> justin_o: ok thanks see you then
[13:37:15 EDT(-0400)] <justin_o> alisonbenjamin: np, see you then
[13:46:13 EDT(-0400)] * michelled (~michelled@142.150.154.101) has joined #fluid-work
[13:46:27 EDT(-0400)] * colinclark (~colin@142.150.154.101) has joined #fluid-work
[13:47:42 EDT(-0400)] <colinclark> Bosmon8: you have added one
[13:48:05 EDT(-0400)] <colinclark> you aren't multiplying, just incrementing
[13:48:09 EDT(-0400)] <colinclark> the Bosmon counter
[13:48:14 EDT(-0400)] <colinclark> Bosmon++?
[13:48:19 EDT(-0400)] <colinclark> ok, I'll be quiet now
[13:48:28 EDT(-0400)] <colinclark> justin_o: how's it going with the jquery upgrade
[13:48:31 EDT(-0400)] <colinclark> things we should talk about here?
[13:49:12 EDT(-0400)] <Bosmon8> Hi
[13:49:41 EDT(-0400)] <justin_o> colinclark: looks like it is going well now... Bosmon8 was able to fix the big remaining issues this morning... i've updated the dependency files and yura and I just did some testing with the infusionAll.js file and they seem to be fine
[13:49:51 EDT(-0400)] <colinclark> that's awesome!
[13:49:53 EDT(-0400)] <colinclark> Bosmon8: Nice work, dude
[13:50:15 EDT(-0400)] <colinclark> So I wanted to talk about a release schedule, unless there are specific tech questions we should talk about first?
[13:51:06 EDT(-0400)] <justin_o> colinclark: we will have to merge into trunk and then make sure engage is all working.. that and updating readmes and maybe writing some wiki docs for any changes is all that is left for this...
[13:51:15 EDT(-0400)] <colinclark> ok
[13:51:19 EDT(-0400)] <justin_o> there may be a question about backwards compatibility but that's all
[13:51:19 EDT(-0400)] * colinclark is always scheming
[13:51:23 EDT(-0400)] <colinclark> So here is my latest scheme...
[13:51:31 EDT(-0400)] <colinclark> I'm wondering if we have an opportunity to do a quick release
[13:51:43 EDT(-0400)] <colinclark> And have it cost us very little in terms of our Infusion 1.2 schedule
[13:52:00 EDT(-0400)] <colinclark> So the idea would be a jQuery-only Infusion 1.1.3 release
[13:52:13 EDT(-0400)] <colinclark> We go through a full QA cycle on it, and get it out the door as soon as we can.
[13:52:21 EDT(-0400)] <colinclark> And then, perhaps Infusion 1.2 will actually be easier
[13:52:32 EDT(-0400)] <colinclark> In that it largely contains a "mobile package"
[13:52:52 EDT(-0400)] <colinclark> So then perhaps we could do a full test of the new stuff for 1.2, along with a quick re-test of the things we've just tested for Infusion 1.1.3
[13:52:56 EDT(-0400)] <colinclark> justin_o: Does this sound insane?
[13:55:04 EDT(-0400)] <justin_o> colinclark: I think it would probably be quicker to do then at the same time.. is there a need to get infusion out earlier
[13:57:21 EDT(-0400)] <colinclark> Well, I think there's a question of responsiveness.
[13:57:32 EDT(-0400)] <colinclark> I know that people are keen to use jQuery 1.4.x, since it's been out for awhile.
[13:58:18 EDT(-0400)] <colinclark> Priority number one is stability
[13:58:31 EDT(-0400)] <colinclark> So we held off on any upgrades for until now for two reasons:
[13:58:42 EDT(-0400)] <colinclark> 1. jQuery usually requires a point release or two before stabilizing
[13:58:51 EDT(-0400)] <colinclark> 2. jQuery UI 1.8 was still under development
[13:59:08 EDT(-0400)] <colinclark> So now that 1.8 is stable and released, it seems like a good time to follow very closely and get Infusion out
[13:59:24 EDT(-0400)] <colinclark> justin_o: You have a lot of influence in this decision
[13:59:37 EDT(-0400)] <colinclark> But my personal feeling is that we should get something out by the end of the week if we can do it.
[14:03:03 EDT(-0400)] <justin_o> colinclark: so i guess there is a couple of things... 1) not sure how much has changed in the trunk since 1.1.2 so this may need to be a 1.2 release. 2) Also when do we need to have the other stuff planned for moving into infusion released
[14:04:39 EDT(-0400)] <colinclark> justin_o: tell me more
[14:05:29 EDT(-0400)] <justin_o> colinclark: so i guess with point 1... it wouldn't save us any time to do a release off of the 1.1.x line if there were lots of changes in trunk.. we would have to do all the tests again
[14:05:46 EDT(-0400)] <colinclark> justin_o: And we're pretty sure there are some substantial changes
[14:06:02 EDT(-0400)] <colinclark> Given that we did things like trim the size of many files, fix a number of Renderer bugs, etc.
[14:06:07 EDT(-0400)] <justin_o> colinclark: not too sure... can't quite remember what has gone in there... so i'll have to take a look at that
[14:06:22 EDT(-0400)] <colinclark> justin_o: I
[14:06:27 EDT(-0400)] <colinclark> I'm pretty sure it's substantial
[14:06:36 EDT(-0400)] <justin_o> i'm guessing mFSS would be the thing that comes to mind.. but that is probably self contained enough that it would be okay
[14:08:44 EDT(-0400)] <justin_o> colinclark: okay... so maybe we should just do a 1.2 release now and then do either a 1.2.1 for the mobile stuff or a 1.3
[14:08:58 EDT(-0400)] <justin_o> i guess it sort of depends on what from engage we want to move up into infusion asap
[14:09:03 EDT(-0400)] <colinclark> yeah
[14:09:05 EDT(-0400)] <justin_o> and in what state
[14:09:12 EDT(-0400)] <colinclark> so you're thinking the cheapest route is to ship what's in trunk asap
[14:09:32 EDT(-0400)] * jhung (~decapod@142.150.154.125) has joined #fluid-work
[14:09:37 EDT(-0400)] <colinclark> and then fill it in with Nav List, Cabinet, and Screen Navigator, along with the latest and greatest mFSS after?
[14:09:46 EDT(-0400)] <justin_o> i think the mFSS is already in trunk
[14:10:56 EDT(-0400)] <colinclark> justin_o: The newest stuff?
[14:14:27 EDT(-0400)] <justin_o> colinclark: yes... mFSS lives in fss in the turnk
[14:14:39 EDT(-0400)] <colinclark> Ok, so I see three scenarios we have to explore:
[14:14:52 EDT(-0400)] <colinclark> 1. An Infusion 1.1.3 release with just the jQuery upgrade
[14:15:18 EDT(-0400)] <colinclark> 2. An Infusion 1.2 release that contains everything in trunk--so basically, all the new stuff except Nav List, Screen Navigator, and Cabinet
[14:15:24 EDT(-0400)] <colinclark> 3. The whole shebang
[14:15:28 EDT(-0400)] <colinclark> Anything in between?
[14:15:38 EDT(-0400)] <colinclark> jessm: you might want to keep half an eye on our discussion here
[14:15:46 EDT(-0400)] <justin_o> colinclark: i think that was it
[14:15:51 EDT(-0400)] <colinclark> ok
[14:15:53 EDT(-0400)] <colinclark> let's see then
[14:17:48 EDT(-0400)] * kasper__ (~kasper@0x5552c030.adsl.cybercity.dk) has joined #fluid-work
[14:18:54 EDT(-0400)] <jessm> colinclark: oh, i am – 1/2_eye_Jess
[14:19:02 EDT(-0400)] <jessm> or .5_i_Jess
[14:19:34 EDT(-0400)] <jessm> so, justin_o colinclark what is gonna highlight one option or another? how do we decide?
[14:21:03 EDT(-0400)] <colinclark> jessm: We're just doing a bit of real-world whiteboarding
[14:21:06 EDT(-0400)] <colinclark> to decide exactly this
[14:21:29 EDT(-0400)] <jessm> colinclark: roger that – has anyone mentioned the KISS principle in your convo yet 
[14:21:56 EDT(-0400)] <Bosmon8> blarg
[14:22:31 EDT(-0400)] <colinclark> blarg?
[14:22:37 EDT(-0400)] <colinclark> jessm:
[14:22:39 EDT(-0400)] <Bosmon8> Principles....
[14:22:48 EDT(-0400)] <Bosmon8> You know how dangerous those are
[14:22:53 EDT(-0400)] <colinclark> lol
[14:22:58 EDT(-0400)] <colinclark> like AXIOMS
[14:23:01 EDT(-0400)] <Bosmon8> Yeah
[14:23:18 EDT(-0400)] <Bosmon8> almost exactly like those
[14:24:16 EDT(-0400)] <Bosmon8> I was chatting to THE KING on Friday that we really want to do something proper with createRendererFunction
[14:24:29 EDT(-0400)] <Bosmon8> I don't think it would be too hard
[14:24:58 EDT(-0400)] <Bosmon8> It is absolutely silly to have to have "backed out" some Engage code into hand-rolled cutpoints again just because we didn't have the utility available
[14:25:41 EDT(-0400)] <colinclark> Bosmon8: Yeah, I wanted to chat about that
[14:25:52 EDT(-0400)] <colinclark> I feel a bit worried about us getting it right before unleashing it on the world
[14:25:58 EDT(-0400)] <colinclark> yet we have undoubtedly benefitted from it already
[14:26:14 EDT(-0400)] <colinclark> gimme a couple of minutes, then let's discuss your idea in depth here
[14:28:25 EDT(-0400)] <Bosmon8> http://www.dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/10000/8000/200/18219/18219.strip.gif
[14:28:30 EDT(-0400)] <Bosmon8> "STATE YOUR IDEA NOW"!
[14:30:54 EDT(-0400)] * EricDalquist (~apollo@76.208.69.152) has joined #fluid-work
[14:31:03 EDT(-0400)] * EricDalquist (~apollo@76.208.69.152) has left #fluid-work
[15:06:55 EDT(-0400)] * jhung (~decapod@142.150.154.125) has left #fluid-work
[15:16:27 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[15:21:40 EDT(-0400)] <justin_o> Bosmon8: colinclark will update you... i'll avoid the large hammer
[15:23:15 EDT(-0400)] <colinclark>
[15:32:58 EDT(-0400)] <Bosmon8> Anyone here?
[15:33:07 EDT(-0400)] <colinclark> sorry
[15:33:07 EDT(-0400)] <colinclark> super distracted
[15:56:45 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[16:06:08 EDT(-0400)] * EverettZ (~chatzilla@74.198.8.70) has joined #fluid-work
[16:06:28 EDT(-0400)] <EverettZ> colinclark: hey, do you have a sec?
[16:06:49 EDT(-0400)] <colinclark> EverettZ: On the phone at the moment, but I should have a sec soon
[16:07:11 EDT(-0400)] <EverettZ> colinclark: ok
[16:13:52 EDT(-0400)] * clown_afk (~clown@142.150.154.202) has left #fluid-work
[16:14:01 EDT(-0400)] * clown_afk (~clown@142.150.154.202) has joined #fluid-work
[16:19:43 EDT(-0400)] <colinclark> Okay, Bosmon8
[16:19:46 EDT(-0400)] <colinclark> are you still around?
[16:20:24 EDT(-0400)] <Bosmon8> Yes
[16:20:26 EDT(-0400)] <Bosmon8> I am still around
[16:20:49 EDT(-0400)] <colinclark> So sorry for such a distracted day
[16:20:51 EDT(-0400)] <colinclark> but I have time now
[16:20:57 EDT(-0400)] <Bosmon8> ok
[16:21:06 EDT(-0400)] <colinclark> First, I hear that you squashed all our jQuery-related bugs
[16:21:10 EDT(-0400)] <colinclark> Thanks so much
[16:21:37 EDT(-0400)] * EverettZ (~chatzilla@74.198.8.70) has joined #fluid-work
[16:21:37 EDT(-0400)] <Bosmon8> Well, I had introduced all of them in the first place
[16:21:42 EDT(-0400)] <colinclark> lol
[16:21:42 EDT(-0400)] <Bosmon8> it's the least I could do
[16:22:22 EDT(-0400)] <colinclark> So justin_o and I talked for awhile today
[16:23:16 EDT(-0400)] <colinclark> We had those three scenarios for a release
[16:23:23 EDT(-0400)] <colinclark> Just cut a 1.1.3 release with the jQuery upgrades
[16:23:33 EDT(-0400)] <colinclark> 2. Cut a "whatever's in trunk" release
[16:23:42 EDT(-0400)] <colinclark> 3. Ship everything in trunk plus the new mobile components
[16:24:24 EDT(-0400)] <colinclark> We did some of the math, and it looks like we can do #2 quite quickly, followed by a release in late April with the mobile components.
[16:24:58 EDT(-0400)] <Bosmon8> Hum
[16:25:04 EDT(-0400)] <Bosmon8> Aren't 1 and 2 practically the same?
[16:25:07 EDT(-0400)] <colinclark> no
[16:25:15 EDT(-0400)] <Bosmon8> I presume by "whatever's in trunk" you mean "whatever's in trunk now"?
[16:25:19 EDT(-0400)] <colinclark> We released 1.1.2 quite awhile ago...
[16:25:26 EDT(-0400)] <Bosmon8> Oh
[16:25:31 EDT(-0400)] <colinclark> I did a full diff between 1.1.2 and trunk, and they're quite different
[16:25:32 EDT(-0400)] <Bosmon8> You mean JUST the jQuery upgrades?
[16:25:32 EDT(-0400)] <colinclark> as you well know
[16:25:36 EDT(-0400)] <colinclark> Bosmon8: Yes
[16:25:40 EDT(-0400)] <Bosmon8> We would just backport my fixes from the branch....
[16:25:42 EDT(-0400)] <colinclark> I think we need to get these out very quickly
[16:25:45 EDT(-0400)] <colinclark> yeah
[16:25:52 EDT(-0400)] <colinclark> but I think it's smarter to do trunk
[16:25:57 EDT(-0400)] <Bosmon8> ok
[16:26:04 EDT(-0400)] <colinclark> There's lots of good stuff in there, all of which is pretty much ready to go
[16:26:13 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[16:27:13 EDT(-0400)] <colinclark> So I guess justin_o knows the scoop best
[16:27:22 EDT(-0400)] <colinclark> But we probably can merge our jQuery upgrade branch into trunk
[16:27:33 EDT(-0400)] <colinclark> and finish up the last fixes before freezing and QAing
[16:27:52 EDT(-0400)] <colinclark> we'll have to update Engage as well, perhaps as a quick b4 release
[16:28:25 EDT(-0400)] <colinclark> So Bosmon8, I guess I'm most interested in chatting about createRendererFunction() and the pseudo components stuff
[16:29:15 EDT(-0400)] <colinclark> which would be slotted into a 1.3 release
[16:29:45 EDT(-0400)] <Bosmon8> ok
[16:30:01 EDT(-0400)] <colinclark> But are there other things you want to chat about now?
[16:30:09 EDT(-0400)] <Bosmon8> Primarily that, for now...
[16:30:19 EDT(-0400)] <Bosmon8> I need to review the latest work on Cabinet &c
[16:30:29 EDT(-0400)] <Bosmon8> But most of that is fairly routine, I think
[16:30:32 EDT(-0400)] <colinclark> ah, yes
[16:30:43 EDT(-0400)] <Bosmon8> We decided, at length, that this component needs a MODEL
[16:31:03 EDT(-0400)] <colinclark> +1 for that
[16:31:06 EDT(-0400)] <Bosmon8>
[16:31:19 EDT(-0400)] <Bosmon8> Surely this idea should be debated on its own merits
[16:31:34 EDT(-0400)] <Bosmon8> It's not as if, after all, we have a commitment to.... AXIOMS
[16:32:01 EDT(-0400)] <colinclark> lol
[16:32:20 EDT(-0400)] <jessm> just principles
[16:32:23 EDT(-0400)] <Bosmon8> !!!
[16:32:26 EDT(-0400)] <Bosmon8> WakinG CATT!
[16:32:40 EDT(-0400)] <jessm>
[16:33:42 EDT(-0400)] <colinclark> So, Bosmon8, I need to catch up on the JIRA you commented on regarding createRendererFunction() etc.
[16:33:45 EDT(-0400)] <colinclark> I will do that now
[16:34:09 EDT(-0400)] <colinclark> But I think we could probably harmonize this stuff with the DOM Binder as we had discussed
[16:34:11 EDT(-0400)] <Bosmon8> I guess the "open end" of the debate is "exactly how much" "render" should be "like a subcomponent"
[16:34:23 EDT(-0400)] <colinclark> Bosmon8: Ah, interesting
[16:34:25 EDT(-0400)] <colinclark> tell me more
[16:34:27 EDT(-0400)] <Bosmon8> I think a new record of 4 quoted items in a 17 words
[16:34:48 EDT(-0400)] <colinclark> "i'm very impressed"
[16:34:54 EDT(-0400)] <Bosmon8> hahahahahahaha
[16:35:09 EDT(-0400)] <Bosmon8> Anyway, yes... I sketched out a block of "putative configuration"
[16:35:44 EDT(-0400)] <Bosmon8> I was thinking that, like "events/selectors" etc. this would become a new standard top-level thing
[16:35:54 EDT(-0400)] <colinclark> the render() function?
[16:35:55 EDT(-0400)] <Bosmon8> yes
[16:35:56 EDT(-0400)] <colinclark> or will it be a Thing?
[16:35:58 EDT(-0400)] <Bosmon8> Well
[16:36:01 EDT(-0400)] <Bosmon8> i think it might be both
[16:36:06 EDT(-0400)] <colinclark> like the DOM Binder
[16:36:18 EDT(-0400)] <Bosmon8> We have already showed our disgraceful colours in a few places, by making functions which have properties hanging off them
[16:36:25 EDT(-0400)] <Bosmon8> I see no reason to discontinue this practice
[16:36:38 EDT(-0400)] <Bosmon8> So, another interesting "open end" to the debate is the relationship with "refreshView"
[16:36:51 EDT(-0400)] <Bosmon8> I guess part of that debate only happened in my mind as we were walking home from the cafe
[16:37:13 EDT(-0400)] <Bosmon8> So, the last thing I mentioned to the KING on Friday was that there is a clear, stereotypical relationship between render() and refreshView
[16:37:26 EDT(-0400)] <Bosmon8> but clearly, that "top-level refreshView" itself needs to be "open for extension"
[16:37:42 EDT(-0400)] <Bosmon8> To borrow a phrase from the confused, stumbling "object-oriented" camp
[16:38:21 EDT(-0400)] <colinclark> Bosmon8: yes, this all makes sense so far
[16:38:59 EDT(-0400)] <Bosmon8> So, I was imagining that what might happen could be, that the "render" "subcomponent", as well as directly being invokable as a function, would expose various other "helpful properties"
[16:39:14 EDT(-0400)] <colinclark> such as?
[16:39:23 EDT(-0400)] <Bosmon8> One of which might be a bare-bones refreshView function that could either be assigned directly to the top-level one, or invoked by a custom one at some point within its lifecycle
[16:40:39 EDT(-0400)] <Bosmon8> I guess we could argue that this thing "itself" is really outside the responsibilities of a thing called a "render function"
[16:40:53 EDT(-0400)] <Bosmon8> Perhaps it should just be a separate, configurable "component"
[16:41:57 EDT(-0400)]
[16:42:02 EDT(-0400)] <Bosmon8> hmm
[16:42:53 EDT(-0400)]
[16:44:58 EDT(-0400)] <colinclark> functions hanging off of functions may drive newcomers insane
[16:46:11 EDT(-0400)] <Bosmon8> Yes
[16:46:21 EDT(-0400)] <Bosmon8> I guess the "global component" model makes a lot more sense
[16:46:31 EDT(-0400)] <colinclark> Bosmon8: Why not do something like we do with the DOM Binder, where there is an actual thing, which has one (or a few) key functions that are promoted to "top-level"?
[16:46:48 EDT(-0400)] <Bosmon8> Ah yes, that makes sense
[16:47:07 EDT(-0400)] <Bosmon8> but I was wondering whether the "stereotypical refreshView" really did just belong as a proper "subcomponent"
[16:47:35 EDT(-0400)] <Bosmon8> It would take the "parent that" as its only argument, as things stand right now
[16:47:38 EDT(-0400)] <Bosmon8> In our IoC-less world
[16:47:54 EDT(-0400)] <Bosmon8> I mean, the issue with making it a top-level component is that its signature might change
[16:48:05 EDT(-0400)] <Bosmon8> But then I guess, with IoC, the signature of practically everything might change
[16:48:14 EDT(-0400)] * kasper__ (~kasper@0x5552c030.adsl.cybercity.dk) has joined #fluid-work
[16:48:22 EDT(-0400)] <colinclark> This is where the "subcomponent" terminology starts to break down... you mean "a function that is resolved via IoC," yes?
[16:48:34 EDT(-0400)] <Bosmon8> The arguments it really needs are i) the function handle of "render()" and ii) the "events" block
[16:48:43 EDT(-0400)] <colinclark> or "by the pseud-IoC we currently have" to be more precise
[16:48:48 EDT(-0400)] <colinclark> pseudo
[16:49:02 EDT(-0400)] <Bosmon8> These are the two stereotypical things that refreshView requires
[16:49:09 EDT(-0400)] <colinclark> yeah
[16:49:11 EDT(-0400)] <Bosmon8> Well... I guess we are in a state of "planning for IoC"
[16:49:20 EDT(-0400)] <colinclark> well, we have something resembling IoC
[16:49:28 EDT(-0400)] <colinclark> hence "pseudo-IoC"
[16:49:35 EDT(-0400)] <Bosmon8> It looks like when you are "planning for IoC", what you do, is that you write things with the exact final signature required
[16:49:41 EDT(-0400)] <Bosmon8> Well, I am talking about REAL IoC
[16:49:46 EDT(-0400)] <colinclark> I suppose the subcomponent terminology will die away when we have real IoC, too
[16:50:18 EDT(-0400)] <Bosmon8> That is, you stop being "over-aggressive" with agglomerating arguments, being fearful of having to provide generic signatures
[16:50:27 EDT(-0400)] <colinclark> yeah
[16:50:50 EDT(-0400)] <Bosmon8> Well.... "full IoC" when it comes, will be sufficiently powerful that we actually needn't plan for it
[16:51:12 EDT(-0400)] <colinclark>
[16:51:49 EDT(-0400)] <Bosmon8> It could easily take apart an object that was originally "that", into a new object which you call "options" which has just the two things you need in the same places
[16:52:26 EDT(-0400)] <Bosmon8> Anyway... what are you thinking?
[16:52:55 EDT(-0400)] <colinclark> sec
[16:53:03 EDT(-0400)] <colinclark> I'm just searching through all existing implementations of refreshView
[16:54:19 EDT(-0400)] <Bosmon8> That sounds like something Data would do
[16:54:28 EDT(-0400)] <colinclark> lol
[16:54:43 EDT(-0400)] <Bosmon8> Infinite numbers of things would flicker on a monitor in ghastly and variable shames
[16:54:44 EDT(-0400)] <Bosmon8> shapes
[16:54:53 EDT(-0400)] <colinclark> I guess our current implementations break down fuzzily into something like this:
[16:55:07 EDT(-0400)] <colinclark> 1. Render
[16:55:12 EDT(-0400)] <colinclark> 2. Zap some some components
[16:55:21 EDT(-0400)] <colinclark> 3. Possibly twiddle with some component state (adjust styling, etc)
[16:55:24 EDT(-0400)] <Bosmon8> Ah yes
[16:55:25 EDT(-0400)] <Bosmon8> The zapping
[16:55:29 EDT(-0400)] <colinclark> 4. Possibly fire an event
[16:55:29 EDT(-0400)] <Bosmon8> The dreadful zapping...
[16:55:34 EDT(-0400)] <colinclark> It's the zapping that is most interesting
[16:55:49 EDT(-0400)] <Bosmon8> Well, perhaps from the point of view of a professional Logician
[16:55:54 EDT(-0400)] <Bosmon8> Personally I just find it distasteful
[16:55:54 EDT(-0400)] <colinclark> It has to happen, but it's really about something else
[16:55:56 EDT(-0400)] <colinclark> if you know what I mean
[16:55:58 EDT(-0400)] <colinclark>
[16:56:04 EDT(-0400)] <Bosmon8> It is about the absence of RENDEROUR ANTIGENS
[16:56:07 EDT(-0400)] <Bosmon8> yes
[16:56:17 EDT(-0400)] <Bosmon8> But actually that is not totally unrelated to our current discussion
[16:56:21 EDT(-0400)] <colinclark> Yes
[16:56:23 EDT(-0400)] <colinclark> I agree
[16:56:25 EDT(-0400)] <Bosmon8> Although I guess we should be careful not to bite off more than we can chew here
[16:56:34 EDT(-0400)] <Bosmon8> But perhaps we can chew more than we think
[16:56:35 EDT(-0400)] <colinclark> But is it really solved entirely by Renderer Antigens
[16:56:35 EDT(-0400)] <colinclark> ?
[16:56:48 EDT(-0400)] <colinclark> Yeah, we have a fair bit of chewing going on already
[16:57:00 EDT(-0400)] <Bosmon8> I guess you mean - "Are renderer antigens the most specific thing which solves this"?
[16:57:11 EDT(-0400)] <colinclark> So, it seems to me that re-rendering is a pretty drastic operation from a DOM perspective
[16:57:34 EDT(-0400)] <colinclark> And we know well that there may be subcomponents that are really only minimally aware of "our world"
[16:57:38 EDT(-0400)] <Bosmon8> With stereotypical "render" and "refreshView", we are not a gigantic rock-heaving distance away from "2-phase initialisation"
[16:57:48 EDT(-0400)] <colinclark> yeah
[16:58:24 EDT(-0400)] <Bosmon8> One thing I mentioned to the KING is that the possibility of "render" being broken out into some variety of "pseudo" subcomponent is that it might then be possible to provide for alternative rendering strategies
[16:58:55 EDT(-0400)] <Bosmon8> Of course, as it stands now, only ones which have a contract which includes the possibility of blasting the entire contents of the DOM below a particular node
[16:59:16 EDT(-0400)] * jhung (~decapod@142.150.154.125) has joined #fluid-work
[16:59:35 EDT(-0400)] <jhung> colinclark: here's the Decapod install script http://wiki.fluidproject.org/display/fluid/Decapod+0.3+Installation+Script
[16:59:40 EDT(-0400)] <colinclark> thanks jhung
[16:59:59 EDT(-0400)] <colinclark> Bosmon8: This is all making my head spin a bit
[17:00:22 EDT(-0400)] <colinclark> not the conversation, exactly, but trying to put my finger on what is needed
[17:01:03 EDT(-0400)] <colinclark> I just wonder if the strategies for rendering could potentially be infinitely variable
[17:01:20 EDT(-0400)] <colinclark> I mean, you might just want some default, which we can probably suitably provide with the stereotypical implementation
[17:01:21 EDT(-0400)] <Bosmon8> Well, they do have to be held to some form of generalisable contract
[17:01:35 EDT(-0400)] <colinclark> such as?
[17:01:35 EDT(-0400)] <Bosmon8> But perhaps the contract could be inferred by an inspection of the type of renderer function found at the far end
[17:02:09 EDT(-0400)] <Bosmon8> The point is, once you can declaratively SEE the form of the render configuration, you could then use it to discover, perhaps, some form of "type annotation"
[17:02:29 EDT(-0400)] <Bosmon8> Well, contracts like, for example, "this implementation destroys all nested markup and attached handlers - you will need to regenerate them"
[17:02:43 EDT(-0400)] <Bosmon8> "this implementation simply performs DOM manipulation and leaves unrelated nodes intact"
[17:02:44 EDT(-0400)] <Bosmon8> etc.
[17:02:44 EDT(-0400)] <colinclark> yeah
[17:03:39 EDT(-0400)] <Bosmon8> Or at the pinaccle - "this implementation supports RENDEROUR ANTIGENS - and will take care of properly propagating recursive instantiation to itself"
[17:04:19 EDT(-0400)] <colinclark> This is a bit tenuous, but it feels like there are really events here that would make for a sensible contract
[17:04:27 EDT(-0400)] <Bosmon8> events?
[17:04:41 EDT(-0400)] <colinclark> well, "this implementation destroys all nested markup and attached handlers - you will need to regenerate them"
[17:05:00 EDT(-0400)] <colinclark> this is really about certain events happening at key times
[17:05:10 EDT(-0400)] <colinclark> and the reaction that others will need to have to them
[17:05:41 EDT(-0400)] <colinclark> I mean, a refreshView() function now might do something like this...
[17:05:42 EDT(-0400)] <colinclark> re-render
[17:05:45 EDT(-0400)] <colinclark> zap subcomponents
[17:05:54 EDT(-0400)] <Bosmon8> hmm
[17:06:11 EDT(-0400)] <colinclark> but it's really a case that "markup has been zapped, if you care, do something about it"
[17:06:17 EDT(-0400)] <colinclark> I dunno if I'm making any sense
[17:06:22 EDT(-0400)] <Bosmon8> interesting...
[17:06:40 EDT(-0400)] <Bosmon8> Well
[17:06:51 EDT(-0400)] <colinclark> I mean, how am I to know that my subcomponents really need to be zapped?
[17:06:57 EDT(-0400)] <Bosmon8> The thing is, I guess the "underlying nature" of the "thing which is the event" is more fundamental
[17:07:12 EDT(-0400)] <Bosmon8> "the thing which you say you are doing" after the markup is zapped, is really just phase 2 of the initialisation
[17:07:32 EDT(-0400)] <Bosmon8> The "name of the thing" would probably be something like "onBindHandlers" rather than "onMarkupZapped"
[17:07:40 EDT(-0400)] <colinclark> yeah
[17:07:46 EDT(-0400)] <Bosmon8> I mean, when we say 2, I guess we really mean 3
[17:07:57 EDT(-0400)] <Bosmon8> There are actually (at least) 3 definable phases of initialisation
[17:08:24 EDT(-0400)] <colinclark> what's the third?
[17:08:30 EDT(-0400)] <Bosmon8> i) construction of the subcomponent tree cascade (using whatever variety of IoC is currently available), ii) construction of markup, iii) binding of events
[17:08:44 EDT(-0400)] <Bosmon8> i) and ii) can occur on the server, and iii) generally can't
[17:09:17 EDT(-0400)] <colinclark> yeah, that makes sense
[17:11:16 EDT(-0400)] <Bosmon8> I guess there is a general discussion about the form of the relationship between "events" and "top-level methods"
[17:11:28 EDT(-0400)] <colinclark> yes
[17:11:32 EDT(-0400)] <Bosmon8> In some cases there is a clear, and desirably "enforceable" relationship
[17:11:54 EDT(-0400)] <Bosmon8> Someone calls a thing called "render", and the thing probably fires things called "onRender", "afterRender"
[17:12:01 EDT(-0400)] <colinclark> I was just going to say, yes
[17:12:23 EDT(-0400)] <Bosmon8> So, you were suggesting that "bindHandlers" also enjoys some form of "eventiness"
[17:12:38 EDT(-0400)] <Bosmon8> But I'm not sure that it really does
[17:12:48 EDT(-0400)] <Bosmon8> I mean, it "looks like it does" because we have a dependence issue
[17:12:55 EDT(-0400)] <colinclark> how is that?
[17:13:22 EDT(-0400)] <Bosmon8> And traditionally (without a working IoC system) the only surefire way to blast dependence issues is through creating events...
[17:13:39 EDT(-0400)] <Bosmon8> Well, it is not very "event-like" because you are really only envisaging a single "handler"
[17:13:51 EDT(-0400)] <Bosmon8> There may be multiple points of "being informed"....
[17:13:53 EDT(-0400)] <Bosmon8> hmm....
[17:14:19 EDT(-0400)] <Bosmon8> I guess there are multiple "subscribers" to this event in the form of all the subcomponents.....
[17:14:51 EDT(-0400)] <colinclark> yeah
[17:14:51 EDT(-0400)] <Bosmon8> It's actually a bit awkward.... I'm not convinced the standard event model is fully up to the challenge
[17:14:59 EDT(-0400)] <colinclark> how come?
[17:15:22 EDT(-0400)] <Bosmon8> If you are really serious about it, you will have a targetted "invalidation" model, in the way that the ancestral (spit*) AWT etc. did
[17:15:45 EDT(-0400)] <Bosmon8> I mean, you may really not be interested to broadcasting to "all" listeners who have registered, but really just the ones that have fallen "in the zone of destruction"
[17:15:51 EDT(-0400)] <colinclark> yeah
[17:16:33 EDT(-0400)] <colinclark> it's funny, i mentioned this to justin earlier
[17:16:34 EDT(-0400)] <Bosmon8> It's certainly an unusual kind of "invalidation"
[17:16:39 EDT(-0400)] <Bosmon8> But I think it fits just the same model
[17:16:55 EDT(-0400)] * clown_afk (~clown@142.150.154.202) has left #fluid-work
[17:18:00 EDT(-0400)] <Bosmon8> A set of flags that run down a tree, indicating "something has been lost here"
[17:18:45 EDT(-0400)] <colinclark>
[17:18:51 EDT(-0400)] <Bosmon8> Anyway, the question is, how much of this problem can we see ourselves biting off for a coming release
[17:18:59 EDT(-0400)] <colinclark> Probably not much of it, I imagine
[17:19:16 EDT(-0400)] <Bosmon8> I would hope that we wouldn't decide that the problem is just too vast and indivisible that we can't do anything about it
[17:19:21 EDT(-0400)] <Bosmon8> That is not what BAMER would do
[17:19:22 EDT(-0400)] <colinclark> I guess the key, to start, is to provide some kind of stereotypical refreshView() implementation, as well as to allow users to configure their own replacement
[17:19:28 EDT(-0400)] <colinclark> Bosmon8: lol
[17:19:47 EDT(-0400)] <Bosmon8> Yes
[17:19:57 EDT(-0400)] <colinclark> So then the next question is, could we do more?
[17:20:16 EDT(-0400)] <Bosmon8> I think at the very least we need to provide "some kind of usable embodiment" of what Engage's "createRendererFunction" provides
[17:20:30 EDT(-0400)] <Bosmon8> I think that "invalidation and zapping" can easily be shelved to a future release
[17:20:34 EDT(-0400)] <colinclark> yes
[17:20:36 EDT(-0400)] <colinclark> Ok, let's break "usable embodiment" down to more specifics...
[17:20:45 EDT(-0400)] <colinclark> It would be great to harmonize it with the DOM Binder
[17:20:52 EDT(-0400)] <colinclark> rather than having the selectorsToIgnore
[17:20:57 EDT(-0400)] <colinclark> right, justin_o?
[17:21:06 EDT(-0400)] <Bosmon8> Well, I think we want something like concrete "types" for render: and refreshView:
[17:21:15 EDT(-0400)] <justin_o> colinclark: agreed
[17:21:25 EDT(-0400)] <Bosmon8> Well.... how would we write what is currently "selectorsToIgnore"?
[17:21:33 EDT(-0400)] <Bosmon8> I don't think we ever decided on a model for that
[17:21:34 EDT(-0400)] <Bosmon8> ?
[17:21:42 EDT(-0400)] <colinclark> Bosmon8: At the egg place, did we not?
[17:21:50 EDT(-0400)] <Bosmon8> Well, did we?
[17:21:56 EDT(-0400)] <Bosmon8> I remember we kicked around alternatives
[17:22:02 EDT(-0400)] <Bosmon8> Although I was very confused that day
[17:22:03 EDT(-0400)] <colinclark> a separate box called rendererSelectors
[17:22:08 EDT(-0400)] <Bosmon8> Ah
[17:22:14 EDT(-0400)] <Bosmon8> ok, fine
[17:22:15 EDT(-0400)] <colinclark> Yeah, perhaps my memory has faded too much, but I thought that one had been fairly clear
[17:22:23 EDT(-0400)] <Bosmon8> cool
[17:22:27 EDT(-0400)] <colinclark> I don't know that we decided where to put it, but it's probably simplest as a sibling to the selectors option
[17:22:34 EDT(-0400)] <Bosmon8> If you remember something, something must have happened
[17:22:59 EDT(-0400)] <colinclark> and it's basically a place to put all of your renderer-specific selectors, under the assumption that they may get messed with during the rendering process
[17:23:12 EDT(-0400)] <colinclark> does that sound about right?
[17:23:17 EDT(-0400)] <Bosmon8> Well
[17:23:38 EDT(-0400)] <Bosmon8> I think we were kicking around whether the existing box named "selectors" should be subdivided, or whether we should have new top-level boxes
[17:23:56 EDT(-0400)] <colinclark> Bosmon8: yeah, we didn't fully determine that
[17:24:32 EDT(-0400)] <Bosmon8> And I vaguely remember some discussion on the issue of "repeatingSelectors"
[17:24:56 EDT(-0400)] <colinclark> hmm, trying to dredge that up
[17:24:59 EDT(-0400)] <colinclark> i actually have some notes
[17:25:02 EDT(-0400)] <Bosmon8> Surely I remember being pleased at some point.... with an idea something like being able to have "structures" supported as the key values in the selector structure?
[17:25:04 EDT(-0400)] <colinclark> perhaps i wrote something
[17:26:16 EDT(-0400)] <colinclark> "structures" being objects instead of plain strings as values?
[17:27:03 EDT(-0400)]
[17:27:13 EDT(-0400)] <colinclark> my notes have nothing on this
[17:27:27 EDT(-0400)] <Bosmon8> yeah
[17:27:29 EDT(-0400)] <Bosmon8> Like that
[17:27:51 EDT(-0400)] <Bosmon8> I was just looking over UIOptions
[17:27:58 EDT(-0400)] <Bosmon8> And puzzling over the fact it seems to use no cutpoints....
[17:28:09 EDT(-0400)] <colinclark> it uses rsf:ids
[17:28:21 EDT(-0400)] <colinclark> I believe there were bugs in the cutpoints when Fish started
[17:28:28 EDT(-0400)] <Bosmon8> ha
[17:28:36 EDT(-0400)] <Bosmon8> SHADES OF THE ANCESTRAL PAST
[17:28:37 EDT(-0400)] <colinclark> I should say
[17:28:42 EDT(-0400)] <colinclark> "bugs in support for cutpoints"
[17:28:49 EDT(-0400)] <Bosmon8> We have so much buried Easter Island Heads in our code...
[17:29:04 EDT(-0400)] <Bosmon8> Future civilizations will speculate about what was responsible
[17:29:07 EDT(-0400)] <colinclark>
[17:30:33 EDT(-0400)] <colinclark> So the question of subdividing the current box
[17:30:36 EDT(-0400)] <colinclark> "selectors"
[17:30:50 EDT(-0400)] <Bosmon8> I guess we really need a new box...
[17:30:53 EDT(-0400)] <colinclark> I guess it means that we have to reserve a property in it for the render selectors
[17:31:02 EDT(-0400)] <colinclark> it does seem simpler just to have a new box
[17:31:06 EDT(-0400)] <Bosmon8> ok
[17:31:09 EDT(-0400)] <colinclark> though it is a drag to add boxes
[17:31:21 EDT(-0400)] <Bosmon8> I guess it is somewhat clearer
[17:31:43 EDT(-0400)] <colinclark> I'd be curious to hear what Fish thinks
[17:31:48 EDT(-0400)] <colinclark> though she's gone home already
[17:32:31 EDT(-0400)] <colinclark> so, then, "render" is a thing
[17:32:37 EDT(-0400)] <Bosmon8> yeah
[17:32:39 EDT(-0400)] <Bosmon8> a thing
[17:32:39 EDT(-0400)] <colinclark> or, something not named "renderer" is a thing
[17:32:44 EDT(-0400)] <colinclark> with a render() function?
[17:32:54 EDT(-0400)] <Bosmon8> urg
[17:32:57 EDT(-0400)] <colinclark> or "render" will be a function-Thing?
[17:33:06 EDT(-0400)] <Bosmon8> I guess the former...
[17:33:16 EDT(-0400)] <colinclark> which former?
[17:33:28 EDT(-0400)] <colinclark> "the thing not known as renderer" is a thing?
[17:33:34 EDT(-0400)] <Bosmon8> We will have some "intrinsic initialisation" of which the "final moral effect" is to assign a function named "render" to the top level
[17:33:41 EDT(-0400)] <colinclark> ok
[17:33:57 EDT(-0400)] <Bosmon8> And IF we discover we have any post facto requirement for access to any state within this thing from the outside, we will follow the DOM binder solution
[17:34:11 EDT(-0400)] <colinclark> Bosmon8: I wonder if we should just do that from the start
[17:34:18 EDT(-0400)] <colinclark> which requires us simply to give it a name
[17:34:22 EDT(-0400)] <Bosmon8> I guess it would help to reserve the name at least
[17:34:22 EDT(-0400)] <colinclark> which will not be "renderer"
[17:34:22 EDT(-0400)] <Bosmon8> Right
[17:34:25 EDT(-0400)] <colinclark> k
[17:34:32 EDT(-0400)] <Bosmon8> Why will it not be "renderer"?
[17:34:43 EDT(-0400)] <colinclark> Well, that will cause us the worst confusion
[17:34:49 EDT(-0400)] <colinclark> Unless you want to rename the Renderer
[17:34:59 EDT(-0400)] <Bosmon8> "THE DOCKTOR"
[17:35:04 EDT(-0400)] <colinclark> lol
[17:35:07 EDT(-0400)] <colinclark> +1
[17:35:24 EDT(-0400)] <Bosmon8> "I'm not just A Docktor"
[17:35:32 EDT(-0400)] <colinclark>
[17:35:58 EDT(-0400)] <yura> colinclark: Bosmon8: I was trying to update engage to use the branched infusion with new jquery but it seems like it fails now on the first steps of initialization
[17:36:14 EDT(-0400)] <Bosmon8> it?
[17:36:20 EDT(-0400)] <yura> kettle
[17:36:26 EDT(-0400)] <Bosmon8> Oh
[17:36:28 EDT(-0400)] <Bosmon8> Kettle
[17:36:39 EDT(-0400)] <yura> this is what i m getting
[17:36:40 EDT(-0400)] <yura> Error evaluating file /home/yura/workspace/fluid-all/fluid-engage-kettle/src/main/webapp/../../../../fluid-infusion/src/webapp/lib/jquery/core/js/jquery.js
[17:36:46 EDT(-0400)] <Bosmon8> I guess I hadn't thought of kettle
[17:36:47 EDT(-0400)] <yura> TypeError: Cannot read property "selected" from undefined (/home/yura/workspace/fluid-all/fluid-engage-kettle/src/main/webapp/../../../../fluid-infusion/src/webapp/lib/jquery/core/js/jquery.js#845)
[17:37:07 EDT(-0400)] <Bosmon8> The problems with that will be failure in the "realism" of our env.js
[17:37:22 EDT(-0400)] <Bosmon8> It was always just one of those cutout facades like the ones they used on the Moon Landings
[17:37:32 EDT(-0400)] <yura>
[17:37:34 EDT(-0400)] <Bosmon8> Just good enough to fool exactly the library that we knew was looking at it
[17:37:48 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has left #fluid-work
[17:38:10 EDT(-0400)] <yura> interesting
[17:38:20 EDT(-0400)] <yura> but env.js doesnt use jquery , does it?
[17:38:27 EDT(-0400)] <Bosmon8> env.js is largely for jquery
[17:38:57 EDT(-0400)] <Bosmon8> The purpose of env.js, in our usage, is largely to fool enough of jquery that it feels like starting up
[17:39:15 EDT(-0400)] <Bosmon8> Here and there it actually provides some useful operations that we even need
[17:39:22 EDT(-0400)] <Bosmon8> But even those are generally operated by jquery
[17:39:29 EDT(-0400)] <Bosmon8> Like XHR for example
[17:40:28 EDT(-0400)] <Bosmon8> So, jQuery 1.4 seems to have a long batch of tricky questions to ask the DOM
[17:40:45 EDT(-0400)] <Bosmon8> In order to find out what "shape of browser" it is looking at
[17:41:05 EDT(-0400)] <Bosmon8> This is all part of their new-found religion to stamp out all explicit browser-based version tests
[17:41:19 EDT(-0400)] <Bosmon8> Unfortunately it looks like this one: // Make sure that a selected-by-default option has a working selected property.
[17:41:19 EDT(-0400)] <Bosmon8> // (WebKit defaults to false instead of true, IE too, if it's in an optgroup)
[17:41:19 EDT(-0400)] <Bosmon8> optSelected: document.createElement("select").appendChild( document.createElement("option") ).selected,
[17:41:31 EDT(-0400)] <Bosmon8> Is not prepared for the reality of "THE CATTT browser"
[17:41:37 EDT(-0400)] <colinclark>
[17:42:22 EDT(-0400)] <Bosmon8> It's actually pretty good that it gets down that far before exploding
[17:42:31 EDT(-0400)] <Bosmon8> That is actually the penultimate test in the set
[17:43:43 EDT(-0400)] <Bosmon8> I'm not totally convinced that this "no browser names" movement is well-founded
[17:43:46 EDT(-0400)] <Bosmon8> But, there it is....
[17:43:50 EDT(-0400)] <colinclark> I wonder if Fragmented CATT has addressed this issue
[17:44:08 EDT(-0400)] <colinclark> The new, million-file Env.js
[17:44:22 EDT(-0400)] <Bosmon8> I assume Fragmented CATTT is being maintained by people more attentive to "DOM reality" than we are...
[17:44:33 EDT(-0400)] <colinclark> I think that's probably true
[17:44:34 EDT(-0400)] <Bosmon8> I mean, they actually intend this thing to WORK
[17:44:41 EDT(-0400)] <colinclark> Thatcher is a nice guy, and has been working a fair bit on it
[17:44:49 EDT(-0400)] <colinclark> But I imagine it's not a trivial upgrade
[17:44:52 EDT(-0400)] <Bosmon8> Since they are using it to actually write apps
[17:44:55 EDT(-0400)] <colinclark> yeah
[17:45:02 EDT(-0400)] <colinclark> Although, to be fair, it's a small community
[17:45:07 EDT(-0400)] <Bosmon8> Rather than just convince people about Moon Landings
[17:45:12 EDT(-0400)] <colinclark> lol
[17:45:34 EDT(-0400)] <Bosmon8> But, we are just diverging further and further from that codebase
[17:45:39 EDT(-0400)] <colinclark> I don't suppose we're in a position to try to drop Fragmented CATTT in?
[17:45:45 EDT(-0400)] <colinclark> How far have we really diverged?
[17:45:48 EDT(-0400)] <Bosmon8> And each time we come to make a decision, the economics are only further against us
[17:46:01 EDT(-0400)] <Bosmon8> Well, we have diverged more than we have, the last time we revisited this question
[17:46:02 EDT(-0400)] <colinclark> I remember a few bugs we've fixed, but I vaguely think they've been fixed there, too
[17:46:16 EDT(-0400)] <Bosmon8> And decided that it was uneconomic to switch over
[17:46:19 EDT(-0400)] <colinclark> Can we enumerate the key divergences?
[17:46:38 EDT(-0400)] <colinclark> I guess we should review whether the economy has rebounded somewhat
[17:46:50 EDT(-0400)] <colinclark> Just in case
[17:46:54 EDT(-0400)] <Bosmon8> I guess
[17:48:35 EDT(-0400)] <Bosmon8> There is a lot of "fix" in the area of copying streams and encoding, etc.
[17:49:07 EDT(-0400)] <Bosmon8> There is a general "fix" to make AJAX default to synchrony which a lot of the surrounding infrastructure depends on
[17:49:12 EDT(-0400)] <colinclark> Yeah
[17:49:20 EDT(-0400)] <Bosmon8> Until we move everything over to "spouts" this would involve touching a lot of code
[17:49:22 EDT(-0400)] <colinclark> I wonder if they may have done the latter fix themselves
[17:49:32 EDT(-0400)] <colinclark> Unfortunately: http://www.envjs.com/
[17:49:49 EDT(-0400)] <Bosmon8> Then there is the responseXML fix
[17:50:13 EDT(-0400)] <Bosmon8> hahaha
[17:50:21 EDT(-0400)] <Bosmon8> CLAYPOOL
[17:51:22 EDT(-0400)] <Bosmon8> You remember that issue relating to "dodgy" documents causing an SAX parsing exception
[17:51:28 EDT(-0400)] <Bosmon8> Even if the renderer could deal with them perfectly well
[17:51:59 EDT(-0400)] <Bosmon8> I guess it could always be worth switching over
[17:52:08 EDT(-0400)] <Bosmon8> But THEN there is the fact that we never modularised kettle
[17:52:23 EDT(-0400)] <Bosmon8> Which means that the zillion fragmented CATTs will end up cluttering our one central includes registry
[17:52:48 EDT(-0400)] <colinclark> I think they've probably diverged too much for us
[17:52:54 EDT(-0400)] <colinclark> I'm just reviewing their mailing list
[17:53:08 EDT(-0400)] <colinclark> Apparently they replaced the HTML parser with something generated by GWT
[17:53:35 EDT(-0400)] <Bosmon8> hah!
[17:53:39 EDT(-0400)] <Bosmon8> Crikey
[17:54:34 EDT(-0400)] <Bosmon8> Thatcher's github is showing continuing strong activity on it
[17:54:53 EDT(-0400)] <colinclark> Yep
[17:54:56 EDT(-0400)] <colinclark> There is a community working on it
[17:55:14 EDT(-0400)] <Bosmon8> But yes, there is stuff here that just doesn't look like Javascript
[17:55:24 EDT(-0400)] <colinclark> There is an email from Chris in late February saying that 197 of 2834 jQuery 1.4.1 tests were failing in Env.js
