[08:30:28 CDT(-0500)] <heidi_> Justin_o did you want to split up the browser testing once the test page is ready or?
[08:31:02 CDT(-0500)] <Justin_o> heidi_: sure we could do that
[08:31:19 CDT(-0500)] <heidi_> Justin_o okay i have winxp here and mac
[08:31:42 CDT(-0500)] <Justin_o> heidi_: thanks... that will save me a bunch of time..
[08:31:53 CDT(-0500)] <heidi_> cool so just lemee know when the test page is ready
[08:33:41 CDT(-0500)] <Justin_o> heidi_: will do... I'll try to get it done asap
[08:36:09 CDT(-0500)] <heidi_> k i'm going to work on creating a component documentation today a bit, didn't get to yesterday, but i'll switch to fss when its ready
[08:45:10 CDT(-0500)] <Avipar> hi, can someone help me out with collin clark's IRC nick
[08:45:24 CDT(-0500)] <Avipar> i submitted my proposal but wanted to discuss
[08:48:53 CDT(-0500)] <Avipar> :/
[08:50:47 CDT(-0500)] <greggy> Avipar: colin's not around yet colin_clark when he is
[08:51:00 CDT(-0500)] <Avipar> aah thanx !
[08:52:15 CDT(-0500)] <greggy> heidi_: you tried Universal Subtitles yet. I spent a good part of the weekend captioning my videos. Very nice tool!
[08:54:38 CDT(-0500)] <heidi_> greggy a little bit - good to hear it works well! that's awesome
[08:54:51 CDT(-0500)] <heidi_> can chat with you a bit about it tomorrow when i'm in maybe
[08:56:12 CDT(-0500)] <greggy> heidi_: okay
[09:22:22 CDT(-0500)] <michelled> Justin_o, anastasiac: what do you think about noting possible API changes on the release status page?
[09:22:30 CDT(-0500)] <michelled> then we could talk about them at dev meetings
[09:23:16 CDT(-0500)] <anastasiac> michelled, do you mean that if a developer thinks something they're doing will change the API for the next release, then they would note that on the release status page?
[09:23:25 CDT(-0500)] <michelled> yes
[09:23:35 CDT(-0500)] <michelled> developers, code reviewers and documentation writers
[09:23:47 CDT(-0500)] <anastasiac> sounds like a good idea; not sure how we'll ensure that people remember to do it
[09:23:54 CDT(-0500)] <michelled> it would be one place to keep track of things things that sometimes slip between the cracks
[09:24:41 CDT(-0500)] <michelled> what seems to happen now is that people keep their own private lists or it's just in people's heads
[09:26:42 CDT(-0500)] <anastasiac> michelled, I'm much in favour of public lists instead of private
[09:27:26 CDT(-0500)] <Justin_o> anastasiac, michelled: i would agree with that
[09:29:24 CDT(-0500)] <Justin_o> harriswong: if you are looking for some work to do... would you mind looking into upgrading our jquery ui version to the latest.. i think that's jquery ui 1.8.11
[09:29:55 CDT(-0500)] <harriswong> justin_o: will do.
[09:29:59 CDT(-0500)] <Justin_o> you should probably create a jira, if there isn't one, and setup a new branch in your github space so that others can follow along
[09:30:11 CDT(-0500)] <michelled> anastasiac, Justin_o: I just put an API change note on the release status page. Take a look and see if you think it fits well there
[09:30:12 CDT(-0500)] <harriswong> justin_o: okay
[09:30:12 CDT(-0500)] <michelled> http://wiki.fluidproject.org/display/fluid/Infusion+1.4+Release+Status
[09:30:53 CDT(-0500)] <colinclark> Morning everyone
[09:31:06 CDT(-0500)] <michelled> morning
[09:31:18 CDT(-0500)] <michelled> Justin_o, anastasiac: if you like it I'll send a note to the list asking everyone to do this
[09:31:53 CDT(-0500)] <anastasiac> michelled, this looks good. we should also think about what to change after we've discussed it and decided to allow it - new heading?
[09:31:54 CDT(-0500)] <Justin_o> michelled: i wonder if we want to organize it a bit, like by component or something
[09:32:17 CDT(-0500)] <michelled> Justin_o: sure - it will make it easier to read that way
[09:32:58 CDT(-0500)] <Justin_o> michelled: thanks
[09:34:58 CDT(-0500)] <jhung> ping anastasiac
[09:35:08 CDT(-0500)] <anastasiac> jhung, polo
[09:35:15 CDT(-0500)] <anastasiac> ah, right!
[09:35:23 CDT(-0500)] <jhung> is erin in the office?
[09:35:27 CDT(-0500)] <anastasiac> not yet
[09:35:42 CDT(-0500)] <jhung> k. Wondering if we should get a head start on this.
[09:35:55 CDT(-0500)] <anastasiac> she just walked in, jhung
[09:35:58 CDT(-0500)] <anastasiac> taking coat off
[09:36:08 CDT(-0500)] <jhung> cool.
[09:40:24 CDT(-0500)] <anastasiac> jhung, we're ready whenever you are
[09:43:30 CDT(-0500)] <colinclark> mlam: I'm thinking it's time to get some Uploader fixes into the project repo today
[09:43:38 CDT(-0500)] <michelled> colinclark: you ok with me updating your clone to the project repo master?
[09:44:06 CDT(-0500)] <colinclark> mlam: I've got two on my list, FLUID-3886 (the fileTypes fix) and the Error Handler View (what's the JIRA for that one again?)
[09:44:07 CDT(-0500)] <mlam> That would be awesome colinclark. It would be good to get some feedback on the pull requests and them in
[09:44:15 CDT(-0500)] <colinclark> Are there any others I'm missing?
[09:44:21 CDT(-0500)] <colinclark> michelled: Go for it
[09:44:26 CDT(-0500)] <colinclark> How could I complain
[09:44:29 CDT(-0500)] <mlam> no, those are the only 2, i'll dig up the other jira number
[09:44:52 CDT(-0500)] <mlam> colinclark: FLUID-3878
[09:45:51 CDT(-0500)] <Justin_o> heidi_: i've added the tabs to the FLUID-4023 manual test page
[09:46:06 CDT(-0500)] <Justin_o> I've pushed this up to my branch in github, so you should be able to update now
[09:46:17 CDT(-0500)] <colinclark> Okay, great, mlam.
[09:46:36 CDT(-0500)] <heidi_> Justin_o so just git pull justin/FLUID-4023 or something?
[09:46:48 CDT(-0500)] <colinclark> So, do you and harriswong want to give me a quick update on what you're busy with on the Uploader at the moment?
[09:47:29 CDT(-0500)] <Justin_o> heidi_: yes.. i guess you have to be in the correct branch first
[09:47:39 CDT(-0500)] <Justin_o> i like to do git fetch repoName
[09:47:54 CDT(-0500)] <heidi_> Justin_o i did git pull justin FLUID-4023 in the right branch
[09:47:55 CDT(-0500)] <Justin_o> then when in my branch do git merge repoName/FLUID-4023
[09:48:11 CDT(-0500)] <Justin_o> heidi_: cool.. it's all working?
[09:48:13 CDT(-0500)] <greggy> colinclark: I'm not finding your ID on GSoC . what was it?
[09:48:19 CDT(-0500)] <heidi_> looking now...
[09:48:29 CDT(-0500)] <Justin_o> I had to add some more dependencies so hopefully i got them all in correctly.
[09:48:55 CDT(-0500)] <colinclark> greggy: I have no idea. If it was my Google account, I can ping you off-channel with it to avoid spam
[09:49:00 CDT(-0500)] <harriswong> colinclark: I was writing some testcases for the Flash version of the Uploader. It tests the .remote(swfUpload, queue, options); i created my own swfUpload and queue and tested if they are called properly, and the flags are set properly after remote() is called
[09:49:10 CDT(-0500)] <heidi_> Justin_o i see the tabs, but it looks kinda weird
[09:49:15 CDT(-0500)] <colinclark> Honestly, I haven't had any time to work with the GSoC site, it's been really busy
[09:49:29 CDT(-0500)] <colinclark> harriswong: Cool
[09:49:35 CDT(-0500)] <colinclark> I'd really like to take a peek
[09:49:40 CDT(-0500)] <greggy> colinclark: okay, or the email address you use with your google account
[09:49:40 CDT(-0500)] <colinclark> can you push it up to your Github repo?
[09:50:03 CDT(-0500)] <heidi_> Justin_o i think we need to clearfix the background
[09:50:12 CDT(-0500)] <heidi_> or not use that grey background
[09:50:15 CDT(-0500)] <harriswong> colinclark: i didn't push it to my git yesterday and it's at my work machine, i will push it up tomorrow morning?
[09:50:59 CDT(-0500)] <heidi_> but the tabs are good i think Justin_o , easier to see the layouts
[09:51:18 CDT(-0500)] <colinclark> harriswong: Yep, whenever you get a chance
[09:51:28 CDT(-0500)] <colinclark> don't forget this is one of the big reasons we switched to github
[09:51:36 CDT(-0500)] <heidi_> Justin_o i'll send a screen shot of the weirdness
[09:51:37 CDT(-0500)] <Justin_o> heidi_: yah... i mentioned that in my commit log
[09:51:44 CDT(-0500)] <heidi_> ah
[09:51:47 CDT(-0500)] <colinclark> so you'd have any easy place to stash your stuff in-progress, work on it anywhere, etc.
[09:52:06 CDT(-0500)] <Justin_o> heidi_: the style is part of the theme...
[09:52:24 CDT(-0500)] <Justin_o> you can hack that if you like or as you say, we can try to clear fix the background too
[09:52:34 CDT(-0500)] <Justin_o> not sure what effect that will have on the rest of the test though
[09:52:49 CDT(-0500)] <Justin_o> heidi_: any preferences?
[09:53:11 CDT(-0500)] <heidi_> Justin_o i think we should avoid using clearfix in the actual test layout
[09:53:23 CDT(-0500)] <heidi_> i sent you a screen shot, there's some other weird stuff
[09:54:07 CDT(-0500)] <colinclark> harriswong: One question for you: what would a unit test for the swfuploadStrategy.remote() actually test?
[09:54:42 CDT(-0500)] <colinclark> It's really only got two lines of code in it--one call to swfUpload.startUpload() (which would clearly fail in a unit test) and one assignment to the shouldStop flag
[09:54:55 CDT(-0500)] <Justin_o> heidi_: just looking at the screenshot, what was the other weird stuff?
[09:54:56 CDT(-0500)] <colinclark> Are you testing IoC resolution of that stuff, or something?
[09:54:58 CDT(-0500)] <colinclark> That would all be useful
[09:55:35 CDT(-0500)] <heidi_> Justin_o the background of the tabs and the container of the tabs having a rounded border... this is all a theme?
[09:55:58 CDT(-0500)] <Justin_o> heidi_: yes
[09:56:07 CDT(-0500)] <Justin_o> it's actually from the fl-theme-slate
[09:56:08 CDT(-0500)] <heidi_> it's kind of terrible- which theme?
[09:56:50 CDT(-0500)] <Justin_o> heidi_: this is generally what jqueryui themes look like though.
[09:56:54 CDT(-0500)] <Justin_o> you can see from here http://jqueryui.com/themeroller/
[09:56:54 CDT(-0500)] <heidi_> can you see how the background of the current page is on top of the tabs?
[09:57:16 CDT(-0500)] <heidi_> wow weird
[09:57:53 CDT(-0500)] <colinclark> mlam: How about you, you're working on building a mock XHR that can handle mock file uploads?
[09:58:07 CDT(-0500)] <heidi_> Justin_o the two colours of grey in the background are strange... anyway, i guess it's besides the point but it looks kinda broken to me
[09:58:20 CDT(-0500)] <harriswong> colinclark: I am testing if the remote() function behaves as it should with the given parameters. ie. if I throw in an object that i have created with the specific attributes, remote should still be able to call them as long as the attributes are there. They don't have to be objects created by the littleComponents. if that makes sense...
[09:58:23 CDT(-0500)] <Justin_o> heidi_:
[09:58:28 CDT(-0500)] <heidi_> :|
[09:58:29 CDT(-0500)] <heidi_> ha
[09:58:34 CDT(-0500)] <Justin_o> we can pick a different theme or you can make a custom one if you like
[09:58:39 CDT(-0500)] <Justin_o> i'm not tied to it at all
[09:58:54 CDT(-0500)] <heidi_> Justin_o it's just a test page, not worth it. but we should fix the clearfix thing... take away the background maybe or use fl-fix on it
[09:59:28 CDT(-0500)] <Justin_o> heidi_: i'm going to play with themeroller and see if we can get something without the background
[09:59:41 CDT(-0500)] <Justin_o> or we can just copy one of our themes and remove the css for it
[09:59:43 CDT(-0500)] <colinclark> harriswong: Hmm, I think so. So you're testing that with a mock SWFUpload, the remote calls its startUpload() method?
[10:00:16 CDT(-0500)] <heidi_> Justin_o i'm confused... this is jquery ui css framework or fss?
[10:01:21 CDT(-0500)] <Justin_o> heidi_: a bit of both... in this case.. basically i used fss versions of the jquery ui custom theme
[10:01:54 CDT(-0500)] <Justin_o> it is used by the fss themes to make the jquery ui widgets match the rest of the fss theme
[10:02:25 CDT(-0500)] <harriswong> colinclark: yes, so when you triggered remote.uploadNextFile(), it should fire swfUpload.startUpload(), whatever that startUpload() does.
[10:02:35 CDT(-0500)] <colinclark> ok
[10:03:04 CDT(-0500)] <harriswong> colinclark: Is there a better way to test the remote method?
[10:03:09 CDT(-0500)] <heidi_> Justin_o mm, ok. well whatever works - wanna add the fl-fix to it?
[10:03:25 CDT(-0500)] <harriswong> colinclark: and the .engine() as well.
[10:03:30 CDT(-0500)] <mlam> colinclark: i had a good conversation with michelled and yura_ yesterday, and they suggest that we don't mock XHR objects at all, since we have to assume that XHR is doing its job
[10:04:10 CDT(-0500)] <Justin_o> heidi_: it's okay.. i'm making a custom theme that just sets the background and border to white
[10:04:12 CDT(-0500)] <colinclark> mlam: that's a demand michelled and I might need to continue here in the channel
[10:04:18 CDT(-0500)] <colinclark> So, I sort of get that argument
[10:04:21 CDT(-0500)] <Justin_o> i think that will be the easiest.. will see if it works
[10:04:23 CDT(-0500)] <heidi_> Justin_o ok
[10:04:33 CDT(-0500)] <colinclark> the key question is, how do we test everything around the calls to XHR?
[10:04:53 CDT(-0500)] <colinclark> In other words, how do we test the code inside html5Strategy.remote(), which are dependent on calling XHR methods?
[10:05:05 CDT(-0500)] <colinclark> michelled: What was your suggestion for that?
[10:05:37 CDT(-0500)] <heidi_> Justin_o why not use the fss tabs instead of adding jquery tabs dependency
[10:05:46 CDT(-0500)] <michelled> my suggestion was to break out all the interesting code into functions that can be tested seperately
[10:06:07 CDT(-0500)] <colinclark> I think we've done that
[10:06:16 CDT(-0500)] <colinclark> and I think many of the methods can be tested in isolation as-is
[10:06:22 CDT(-0500)] <colinclark> but how do you ensure they work together?
[10:06:43 CDT(-0500)] <mlam> yeah, i found that quite challenging. I separated out the XHR creator object into it's own function so that a mock XHR object wouldn't be in the way. But afterwards, I found that the rest of the functionality depended on a valid XHR listener for the XHR's onreadystatechange
[10:07:30 CDT(-0500)] <michelled> colinclark: I don't think I understand what you are trying to test. Is it the order of how things get called?
[10:07:51 CDT(-0500)] <colinclark> Well, I'll put it flippantly
[10:07:55 CDT(-0500)] <colinclark> and you can forgive me for it
[10:08:05 CDT(-0500)] <colinclark> I think mlam wants to test that the thing actually works
[10:09:06 CDT(-0500)] <colinclark> So, I guess it breaks down into two tasks
[10:09:24 CDT(-0500)] <colinclark> 1. Testing that the model gets updated correctly according to certain actions
[10:09:32 CDT(-0500)] <colinclark> such as "upload next file" or whatever
[10:09:50 CDT(-0500)] <colinclark> 2. Ensure that the right sequence of calls and events occur for those actions
[10:10:26 CDT(-0500)] <colinclark> eg. "get the file from the queue, ensure that its state is updated accordingly, then the uploadStart() event fires, then we call the XHR, then a series of progress events fire, etc."
[10:10:30 CDT(-0500)] <colinclark> Does that seem about right, mlam?
[10:11:43 CDT(-0500)] <mlam> yeah, it does colinclark. i'm working on #2 as we speak. I'm testing that the event sequeunce is correct for the fileSuccessHandler, fileErrorHandler and fileStopHandler.
[10:15:12 CDT(-0500)] <mlam> I see michelled's point though. harriswong is writing unit tests for the SWF remote. To fully mock a swfUpload object to test the SWF remote, it seems like we're testing to see if SWF actually works.
[10:15:13 CDT(-0500)] <michelled> my first instinct would have been to test the stuff before the XHR separately from the stuff after the XHR. but you two know the code and the likely breakage points better then me
[10:15:46 CDT(-0500)] <michelled> I would love tests the test whether the thing actually works with a real XHR and a server but of course that's a different level of testing
[10:16:13 CDT(-0500)] <Justin_o> heidi_: okay.. i've added a new custom theme
[10:16:16 CDT(-0500)] <Justin_o> please take a look now
[10:16:33 CDT(-0500)] <Justin_o> not that the theme seems to have affected the style of the fonts.. i think this is okay, but let me know what you think
[10:16:34 CDT(-0500)] <colinclark> Well, the point of mocking is specifically not to test that something works, by taking it out of the equation entirely.
[10:17:30 CDT(-0500)] <colinclark> I think the point about testing the SWF remote is that it's so trivial to mock the single call to SWFUpload that it's almost not worth doing. I'm sure harriswong was able to whip out that test pretty fast
[10:17:59 CDT(-0500)] <colinclark> In this case, we're a bit more dependent on XHR, but it still shouldn't be terribly difficult to mock out our dependency on it
[10:18:48 CDT(-0500)] <colinclark> Uploader is systemically lacking tests, and there are two sorts of tests we desperately need:
[10:19:05 CDT(-0500)] <colinclark> 1. Individual unit tests that test all functionality of a given object in isolation
[10:19:21 CDT(-0500)] <heidi_> Justin_o better, thanks. shall we split up testing? do you have a file for the clearfix notes you sent out on the list? looked like a spreadsheet maybe?
[10:19:43 CDT(-0500)] <colinclark> 2. Integration tests, showing that in context of other objects, things are working nicely
[10:19:53 CDT(-0500)] <colinclark> We've been burned by a lack of #2 over the past couple of weeks
[10:20:00 CDT(-0500)] <Justin_o> heidi_: i do.. i'll send that to you
[10:20:24 CDT(-0500)] <colinclark> It seems to me that the demo remote gets us part way towards writing any kind of integration test we want
[10:21:04 CDT(-0500)] <colinclark> But the approach the demo remote uses is to take 1/4 of Uploader's internals and mock them out
[10:21:18 CDT(-0500)] <Justin_o> heidi_: I made it using Numbers. Do you have that?
[10:21:23 CDT(-0500)] <colinclark> So, mocking a finer level of granularity should solve our problem...
[10:21:56 CDT(-0500)] <colinclark> In other words, in the case of the HTML5Strategy, if we can remove the dependency on the XHR, we can test any piece of it in isolation or together
[10:22:05 CDT(-0500)] <heidi_> Justin_o i don't, can you save it as anything else?
[10:22:28 CDT(-0500)] <Justin_o> heidi_: sure.. i'll convert it to an excel spreadsheet
[10:22:29 CDT(-0500)] <michelled> colinclark: ok, that makes sense
[10:22:38 CDT(-0500)] <heidi_> Justin_o cool thanks
[10:22:55 CDT(-0500)] <michelled> I thought you were trying to write unit tests by mocking things out which felt to me like a factoring issue
[10:23:17 CDT(-0500)] <michelled> but if you're actually attempting to write some integration tests mocks make sense
[10:23:17 CDT(-0500)] <colinclark> michelled: Okay, I'm still confused
[10:23:23 CDT(-0500)] <colinclark> If you have to objects
[10:23:24 CDT(-0500)] <colinclark> A and B
[10:23:27 CDT(-0500)] <colinclark> and A depends on B
[10:23:39 CDT(-0500)] <colinclark> In other words, methods in A call methods on B
[10:23:45 CDT(-0500)] <colinclark> How do you unit test A?
[10:24:58 CDT(-0500)] <michelled> if all A does is call things on B then do you unit test A?
[10:25:20 CDT(-0500)] <michelled> if A does other interesting things then perhaps it should be pulled into C and C should be unit tested
[10:25:26 CDT(-0500)] <michelled> am I making sense?
[10:26:13 CDT(-0500)] <colinclark> I don't know
[10:26:16 CDT(-0500)] <colinclark> So, let's break it down
[10:26:22 CDT(-0500)] <colinclark> get a little tiny bit less abstract--but not much
[10:26:29 CDT(-0500)] <colinclark> A implements foo()
[10:26:30 CDT(-0500)] <Justin_o> heidi_: i just e-mailed you the file
[10:26:37 CDT(-0500)] <heidi_> k thanks
[10:26:40 CDT(-0500)] <Justin_o> what configs will you test?
[10:26:48 CDT(-0500)] <colinclark> foo() consists of two lines of code
[10:26:57 CDT(-0500)] <colinclark> 1. A.model = "yay";
[10:26:57 CDT(-0500)] <heidi_> i can do winxp browsers and mac
[10:27:04 CDT(-0500)] <colinclark> 2. B.bar()
[10:27:17 CDT(-0500)] <Justin_o> heidi_: do you have FF4 and FF 3.6 on your mac?
[10:27:27 CDT(-0500)] <heidi_> Justin_o just 3.6, you?
[10:27:34 CDT(-0500)] <colinclark> What is your suggestion for unit testing A.foo(), michelled?
[10:27:39 CDT(-0500)] <Justin_o> heidi_: yep
[10:27:40 CDT(-0500)] <Justin_o> i have that
[10:27:50 CDT(-0500)] <Justin_o> and you have ie 6 - 8 on win xp?
[10:28:19 CDT(-0500)] <Justin_o> heidi_: ^
[10:28:48 CDT(-0500)] <heidi_> Justin_o i'll ping you on idrc chat to make room for the other discussion here! maybe let's make a full browser list to test... just a grades?
[10:29:06 CDT(-0500)] <colinclark> michelled: I assume the goal of the test, written in English, would be "test A.foo() to ensure that the model gets updated to 'yay' and that B's bar() method is called afterwards"
[10:29:50 CDT(-0500)] <michelled> colinclark: that unit test seems to know too much about the implementation details. that's what I don't like about testing with mocks
[10:30:22 CDT(-0500)] <michelled> I prefer black box tests - they are more likely to last through future refactoring
[10:30:33 CDT(-0500)] <colinclark> Okay, so what's the black box equivalent?
[10:32:15 CDT(-0500)] <michelled> set up your test, call A.foo, check that what ever foo is supposed to accomplish has been accomplished. of course with the dependency you either need a B or you need to stub or mock up B
[10:32:49 CDT(-0500)] <colinclark>
[10:43:01 CDT(-0500)] <colinclark> michelled: So, I think we're agreeing now?
[10:47:25 CDT(-0500)] <michelled> colinclark: I was never disagreeing - I just feel that we should avoid testing implementation detail where we can
[10:47:49 CDT(-0500)] <colinclark> I think that point is still too subtle for my half-baked brain
[10:48:03 CDT(-0500)] <colinclark> So, I was thinking about CollectionSpace
[10:48:11 CDT(-0500)] <colinclark> We went through exactly this issue there
[10:48:20 CDT(-0500)] <colinclark> and unfortunately didn't tackle it very well at first
[10:48:31 CDT(-0500)] <colinclark> So, we had components that needed to make XHR requests for whatever reason
[10:48:38 CDT(-0500)] <colinclark> get some data, grab a template, send some data, whatever
[10:48:50 CDT(-0500)] <colinclark> Dealing with it in an ad-hoc way caused lots of spaghetti
[10:49:11 CDT(-0500)] <colinclark> Things started sorting themselves out when we built abstractions around our network requests
[10:49:31 CDT(-0500)] <colinclark> and then used IoC to either reconfigure a component or mock up a dependency for testing
[10:49:41 CDT(-0500)] <colinclark> So, in yura_'s unit tests now
[10:50:00 CDT(-0500)] <colinclark> there's always a demands block that wires stuff up appropriately for a testing context, right?
[10:53:08 CDT(-0500)] <michelled> yes, there are demands intended for a testing context
[10:56:56 CDT(-0500)] <colinclark> mlam: Okay, so how far did you get yesterday with writing new unit tests for Uploader?
[10:57:09 CDT(-0500)] <colinclark> Was it still sort of researchy, or did you get to the point where you got some new green bars?
[10:58:21 CDT(-0500)] <mlam> i covered tests for the progressTracker, i added simple tests for enabling/disabling the browseButton in local. i'm currently working on testing the sequence of the fileSuccessHandler....
[10:58:36 CDT(-0500)] <mlam> the early parts of the afternoon was research-based on mocking XHR
[10:58:59 CDT(-0500)] <colinclark> okay, cool
[10:59:11 CDT(-0500)] <colinclark> Keep going on that
[10:59:17 CDT(-0500)] <colinclark> I'll come into the office shorlty
[10:59:25 CDT(-0500)] <colinclark> we can talk more about a mock XHR
[10:59:56 CDT(-0500)] <colinclark> Can you do me one favour before then?
[11:00:21 CDT(-0500)] <mlam> Sure
[11:00:47 CDT(-0500)] <colinclark> Can you make sure your branches are up to date for FLUID-3878 and 3886?
[11:00:56 CDT(-0500)] <colinclark> That'll make them super easy to review and push
[11:00:58 CDT(-0500)] <mlam> Ok
[11:02:11 CDT(-0500)] <colinclark> thanks
[11:02:13 CDT(-0500)] <mlam> np
[11:02:15 CDT(-0500)] <colinclark> see you soon
[11:22:32 CDT(-0500)] <harriswong> justin_o: can you please remind me how to "download" my branch and master off github?
[11:22:58 CDT(-0500)] <Justin_o> harriswong: what do you mean by download exactly... did you already clone the repo?
[11:23:29 CDT(-0500)] <harriswong> justin_o: i have my master, branches on github, I just want to get it on my machine.
[11:24:31 CDT(-0500)] <Justin_o> harriswong: okay.. first thing you'll need to do is clone it
[11:24:40 CDT(-0500)] <Justin_o> on github you'll see a url
[11:24:48 CDT(-0500)] <Justin_o> make sure you're logged in and you use the git one
[11:25:10 CDT(-0500)] <Justin_o> then on your machine you'll do this "git clone repoURL"
[11:25:37 CDT(-0500)] <Justin_o> that will clone the repo on your machine with the master branch set as the active branch
[11:26:25 CDT(-0500)] <Justin_o> sorry should have said, use the ssh url
[11:26:46 CDT(-0500)] <Justin_o> here's an example of the one to my repo git@github.com:jobara/infusion.git
[11:27:01 CDT(-0500)] <Justin_o> harriswong: ^
[11:28:06 CDT(-0500)] <harriswong> justin_o: thanks! and how would I add the "upstream" again?
[11:28:22 CDT(-0500)] <harriswong> justin_o: which it should points to infusion
[11:28:41 CDT(-0500)] <Justin_o> harriswong: yes... so you could do something like this
[11:28:48 CDT(-0500)] <Justin_o> git remote add upstream git://github.com/fluid-project/infusion.git
[11:32:06 CDT(-0500)] <harriswong> justin_o: i did a git branch -a, but i don't see the upstream for some reasons..
[11:32:29 CDT(-0500)] <Justin_o> harriswong: you added the remote?
[11:32:45 CDT(-0500)] <harriswong> justin_o: i ran "git remote add upstream git://github.com/fluid-project/infusion.git"
[11:33:02 CDT(-0500)] <Justin_o> you also have to do git fetch upstream
[11:33:02 CDT(-0500)] <Justin_o> then you'll be able to see the upstream branches
[11:35:00 CDT(-0500)] <harriswong> justin_o: Thanks!
[11:35:39 CDT(-0500)] <Justin_o> harriswong: np... let me know if you have any more questions
[11:37:08 CDT(-0500)] <harriswong> justin_o: Sure thanks! I am going to merge my local master with the upstream/master. So i did a git log ^master upstream/master; and git log master ^upstream/master, seems right
[11:37:25 CDT(-0500)] <harriswong> justin_o: then i am about to do a git merge upstream/master, is this right?
[11:38:39 CDT(-0500)] <Justin_o> harriswong: that looks good..
[11:40:05 CDT(-0500)] <harriswong> thanks a lot justin_o
[11:41:32 CDT(-0500)] <Justin_o> harriswong: no problem
[11:45:51 CDT(-0500)] <michelled> anastasiac: where do we note that things are deprecated in the docs?
[11:46:13 CDT(-0500)] <michelled> the first argument to fluid.defaults should be deprecated
[11:46:25 CDT(-0500)] <anastasiac> michelled, basically right with whatever is deprecated.
[11:46:44 CDT(-0500)] <anastasiac> so I'd say on the API page, make a note with that first argument
[11:48:22 CDT(-0500)] <michelled> anastasiac: here? http://wiki.fluidproject.org/display/docs/fluid.defaults
[11:49:12 CDT(-0500)] <anastasiac> michelled, yes, on that page: where 'global' is described, note that it's deprecated as of vX.X
[11:49:26 CDT(-0500)] <anastasiac> I suppose elsewhere, where it's mentioned/used in examples, we should also fix, michelled
[12:42:09 CDT(-0500)] <heidi_> Justin_o need to fix html on the mixed col test - you there?
[12:43:35 CDT(-0500)] <Justin_o> heidi_: sorry.. was chatting with colinclark
[12:43:41 CDT(-0500)] <heidi_> np
[12:43:53 CDT(-0500)] <Justin_o> heidi_: do you want to send me a patch.. or i can merge in your branch
[12:44:45 CDT(-0500)] <heidi_> Justin_o can i tell you the change? it's quick. not sure if yr getting my idrc msgs
[12:45:42 CDT(-0500)] <Justin_o> heidi_: sorry.. yes
[12:45:48 CDT(-0500)] <harriswong> mlam, bosmon2: i am trying to merge FLUID-3878 with master and i am having a few conflicts, I think some are related to bosmon2 recent commits for FLUID-4130
[12:46:44 CDT(-0500)] <mlam> harriswong: are you unsure of what changes to keep and discard?
[12:46:58 CDT(-0500)] <harriswong> mlam, bosmon2: the conflicts are on FlashUploaderSupport.js and HTML5UploaderSupport.js.
[12:47:57 CDT(-0500)] <mlam> can you be more specific?
[12:48:04 CDT(-0500)] <harriswong> mlam: yes. I
[12:48:27 CDT(-0500)] <harriswong> mlam: type: "fluid.uploader.swfUploadStrategy.local", vs type: "fluid.uploader.local"
[12:48:39 CDT(-0500)] <harriswong> mlam: one is being used in the current errorHandler, the other is by bosmon2
[12:48:45 CDT(-0500)] <mlam> right
[12:49:23 CDT(-0500)] <harriswong> mlam: i am thinking it should be the latter?
[12:49:25 CDT(-0500)] <mlam> the best way for me in determining what to keep is to look at the source on trunk and do the comparison there.
[13:04:09 CDT(-0500)] <jhung> jessm: ping. Do you have time this aft to quickly chat about tech doc navigation?
[13:04:23 CDT(-0500)] <jessm> jhung: if it's quick, yes
[13:05:11 CDT(-0500)] <jhung> jessm: k. Let me know when is good for you. Erin and anastasiac will join too.
[13:05:55 CDT(-0500)] <jhung> jessm: for you to look at before we chat...
[13:06:28 CDT(-0500)] <jhung> jessm: the evolving document structure for the site. http://wiki.fluidproject.org/download/attachments/22250245/Infusion+Documentation+Website.png?version=6&modificationDate=1301421654570
[13:06:55 CDT(-0500)] <jhung> jessm: early designs for navigating that structure http://wiki.fluidproject.org/display/fluid/Fluid+style+suggest+and+experimentation#Fluidstylesuggestandexperimentation-DocumentationErinbrainstorming
[13:34:09 CDT(-0500)] <mlam> Justin_o: what's our etiquette with deleting branches on our repo? Even though the changes of the branches have been pushed into master, there are sometimes valuable comments relating to the commits.
[13:34:56 CDT(-0500)] <Justin_o> mlam: I think these comments get copied into the main repo when the pull requests are accepted
[13:35:11 CDT(-0500)] <mlam> ahh ok, that's good!
[13:35:31 CDT(-0500)] <Justin_o> mlam: to double check this you can take a look at one of your commits that had comments, from the project repo
[13:35:40 CDT(-0500)] <mlam> ok
[13:36:13 CDT(-0500)] <mlam> ok, i see it. thanks
[13:36:15 CDT(-0500)] <colinclark> fluid-everyone: I've updated the Infusion 1.4 roadmap based on some of the planning conversations I had with everyone yesterday: http://wiki.fluidproject.org/display/fluid/Infusion+Roadmap+1.3.1+-+1.4
[13:36:24 CDT(-0500)] <Justin_o> mlam: great
[13:36:54 CDT(-0500)] <colinclark> We have a few overriding goals: 1. Make UI Options awesome, based on jameswy's wireframes; 2. Improve the FSS; 3. Targetted bug fixes, features, and test coverage for the Uploader
[13:37:09 CDT(-0500)] <colinclark> Our mission with the Uploader is to try to wind that work down by the end of the week
[13:37:53 CDT(-0500)] <colinclark> Consisting of: a) new demo server (cindyli); b) Error Handler View (mlam and harriswong); c) consistent file type support (mlam); d) improved test coverage (mlam and harriswong)
[13:38:38 CDT(-0500)] <colinclark> Justin_o and heidi_: Your roadmap is looking really good--New clear fix and FSS reset, removal of !important, and contribution of new form and portlet styles
[13:38:49 CDT(-0500)] <Bosmon2> I noticed an interesting phenomenon with the SWF Uploader, mlam, colinclark
[13:38:55 CDT(-0500)] <Bosmon2> In that it will refuse to accept files of 0 length
[13:38:58 CDT(-0500)] <Bosmon2> Was this a known issue?
[13:39:13 CDT(-0500)] <heidi_> colinclark cool thanks. it's funny how hard some of these decisions are. a chat on thurs will be nice
[13:39:32 CDT(-0500)] <mlam> Bosmon2: Yes, there should be a JIRA of that somewhere....it was filed years ago
[13:39:33 CDT(-0500)] <colinclark> heidi_: Yep, that meeting will be really helpful, I think
[13:39:42 CDT(-0500)] <Bosmon2> Ok, thanks
[13:39:45 CDT(-0500)] <mlam> np
[13:39:55 CDT(-0500)] <colinclark> michelled, cindyli, and jameswy: UI Options' roadmap looks pretty well defined in JIRA, right? Make the preview a subcomponent, make it a Renderer Component, and implement jameswy's new look and feel.
[13:40:48 CDT(-0500)] <colinclark> anastasiac: Seems like your main missions involve leading sprints, writing priority documentation for 1.4 (FSS, UI Options in particular), reviewing potential API changes, and continuing with what jessm called "nimble demos" in context of the various doc systems you're evaluating
[13:40:55 CDT(-0500)] <colinclark> Does that seem about right? Am I missing anything?
[13:41:22 CDT(-0500)] <colinclark> Bosmon2: You've got framework stabilization as your main mission, followed by a proof of concept preferences server with Kettle?
[13:41:26 CDT(-0500)] <Justin_o> colinclark: jquery and jquery ui update
[13:41:30 CDT(-0500)] <colinclark> ah!
[13:41:35 CDT(-0500)] <Bosmon2> Yes, that's right
[13:41:36 CDT(-0500)] <anastasiac> colinclark, only finalizing the choice of docs platform and getting one up and running
[13:41:43 CDT(-0500)] <colinclark> Justin_o: Remind me who has that mission?
[13:42:35 CDT(-0500)] <Justin_o> colinclark: currenlty jkremer has been looking into it
[13:42:53 CDT(-0500)] <Justin_o> harriswong: is looking at the jquery ui update today as well... i guess in between uploader work
[13:43:01 CDT(-0500)] <colinclark> ok
[13:43:20 CDT(-0500)] <Justin_o> colinclark: this is a necessary upgrade for 1.4 though, for us to meet a-grade browser support
[13:43:22 CDT(-0500)] <colinclark> So, jQuery 1.5 and UI 1.8 are a package, and jkremer and harriswong are going to work on that?
[13:43:24 CDT(-0500)] <Justin_o> so we'll need to get it done
[13:43:42 CDT(-0500)] <colinclark> anastasiac: Do you think it's feasible to get a doc platform chosen, set up, and migrated to in the next few weeks? Seems like there's a lot in there
[13:43:43 CDT(-0500)] <Justin_o> colinclark: i wouldn't say they are a package
[13:43:47 CDT(-0500)] <colinclark> ok
[13:43:53 CDT(-0500)] <anastasiac> colinclark, no, but the work needs to continue
[13:43:59 CDT(-0500)] <Justin_o> I don't necessarily think they are dependent on each other
[13:44:15 CDT(-0500)] <anastasiac> also, colinclark, the roadmap for 1.4 doesn't actually list the same priority docs you've listed here - do you want me to update that?
[13:44:45 CDT(-0500)] <anastasiac> it mentions renderer, not fss
[13:45:11 CDT(-0500)] <colinclark> anastasiac: You tell me what you think the priority documentation should be, and I'll listen
[13:45:19 CDT(-0500)] <colinclark> I listed those two since our main themes for 1.4 are UI Options and FSS
[13:45:21 CDT(-0500)] <colinclark> so it made sense
[13:45:36 CDT(-0500)] <colinclark> Okay, so anastasiac, just so I understand...
[13:45:50 CDT(-0500)] <anastasiac> I agree, those should be the priority. I'm just noticing that the roadmap doesn't say they're the priority for docs, that's all. I'll update it
[13:46:09 CDT(-0500)] <colinclark> you want to treat the documentation platform evaluation and selection work as an ongoing task over the course of the next few releases?
[13:46:55 CDT(-0500)] <anastasiac> colinclark: I don't want to drop the evaluation work entirely until after 1.4, that's all. it's an ongoing task
[13:47:05 CDT(-0500)] <colinclark> ok
[13:47:08 CDT(-0500)] <colinclark> I think that makes tons of sense
[13:47:22 CDT(-0500)] <colinclark> So, what portion of ongoing time do you think it should take up?
[13:47:36 CDT(-0500)] <anastasiac> good question
[13:48:09 CDT(-0500)] <anastasiac> colinclark, ~ apr 5 is still the estimate for 1.4?
[13:49:55 CDT(-0500)] <anastasiac> if it is: well, in that case I think the platform evals would have to be put on hold - that's only 1.5 weeks away. I'd have to focus on the UI Opt and FSS docs primarily first, then see how we do
[13:50:53 CDT(-0500)] <colinclark> Justin_o: We're looking at later April now, right?
[13:51:45 CDT(-0500)] <colinclark> I'm quite keen to see the documentation evaluation, as you say, being something we don't stop doing... we just do it in an ongoing way for some percentage of our time
[13:51:48 CDT(-0500)] <Justin_o> colinclark: yes.. end of april beginning of may for the release
[13:52:13 CDT(-0500)] <anastasiac> so if late april: maybe 20, 25% on evals, 50% on docs, 20-25% on "nimble demos"
[13:52:18 CDT(-0500)] <colinclark> recognizing that our #1 doc priority should be organizing doc sprints and trying to keep the volume and quality of our docs growing
[13:52:26 CDT(-0500)] <colinclark> that sounds awesome, anastasiac
[13:52:37 CDT(-0500)] <colinclark> jessm: When you're done with your meeting, do you think this sounds cool?
[13:53:51 CDT(-0500)] <colinclark> So anything else I'm missing?
[13:54:03 CDT(-0500)] <colinclark> Or is there anything that seems too ambitious for our time line? Or not ambitious enough?
[13:54:06 CDT(-0500)] <colinclark> Or not awesome/
[13:54:13 CDT(-0500)] <colinclark> Or too damn awesome for our own good?
[13:54:17 CDT(-0500)] <colinclark> That would be nice
[13:54:48 CDT(-0500)] <colinclark> mlam and harriswong: Am I dreaming to think that we can wind down the Uploader this week?
[13:54:54 CDT(-0500)] <colinclark> Meaning, really solid unit test coverage
[13:54:57 CDT(-0500)] <colinclark> for all the code
[13:55:05 CDT(-0500)] <colinclark> and those two features I need to review?
[13:55:07 CDT(-0500)] <mlam> No, i dont' think so
[13:55:28 CDT(-0500)] <colinclark> mlam: I was thinking you, me, and Bosmon2 could chat XHR mocking here in a few minutes
[13:56:24 CDT(-0500)] <mlam> I would imagine some minor changes for both branches to pass code standards, and then the unit tests...which SWF should be closer to finishing than HTML5 and the only thing missing from the HTML5 tests now is the XHR tests
[13:56:29 CDT(-0500)] <mlam> colinclark: sounds good
[13:56:37 CDT(-0500)] <colinclark> ok, makes sense
[13:56:42 CDT(-0500)] <colinclark> this is good
[13:56:46 CDT(-0500)] <colinclark> we have a plan
[13:57:04 CDT(-0500)] <colinclark> Aviper: Sorry I missed you earlier
[13:57:19 CDT(-0500)] <Aviper> aah thats fine
[13:57:23 CDT(-0500)] <colinclark> You were interested in applying for our video GSoC project, right?
[13:57:35 CDT(-0500)] <Aviper> indeed !
[13:57:40 CDT(-0500)] <colinclark> That's great!
[13:58:08 CDT(-0500)] <colinclark> You had a demo you'd been working on?
[13:58:08 CDT(-0500)] <Aviper> i tried out some stuff with that and made up a kinda working demo with few components
[13:58:13 CDT(-0500)] <colinclark> cool
[13:58:27 CDT(-0500)] <Aviper> yaa actually i wanted to chk what i can do …i mean real time edit and stuff
[13:58:29 CDT(-0500)] <Aviper> syncing
[13:58:53 CDT(-0500)] <Aviper> soo yaa came up with a demo sort of..
[13:59:09 CDT(-0500)] <Aviper> to get a fair idea and the intensity of the project
[14:00:39 CDT(-0500)] <Aviper> http://globaldelight.com/html5video/
[14:00:45 CDT(-0500)] <Aviper>
[14:04:35 CDT(-0500)] <Bosmon2> So, mlam, colinclark - a framework I found that seemed very useful for XHR mocking was called "MockJax"
[14:04:41 CDT(-0500)] <Bosmon2> I don't know if you had run into this yet
[14:05:14 CDT(-0500)] <michelled> Bosmon2: colinclark was showing me MockJax this afternoon
[14:05:29 CDT(-0500)] <michelled> I believe it's not quite good enough because it doesn't support file upload
[14:05:29 CDT(-0500)] <Bosmon2> You can see some use I make of it in "CachingTests.js" which is in the core framework
[14:05:42 CDT(-0500)] <Bosmon2> Well, I think that is an easy extension
[14:05:47 CDT(-0500)] <colinclark> Aviper: I like what you've done!
[14:05:50 CDT(-0500)] <colinclark> Nice work
[14:05:56 CDT(-0500)] <Aviper> aah thanx...
[14:05:57 CDT(-0500)] <Bosmon2> Compared to taking some more crummy library that might already have support for file upload
[14:06:03 CDT(-0500)] <colinclark> So, the next step, I believe, is to apply with Google
[14:06:10 CDT(-0500)] <Bosmon2> It is an easy framework to extend, I found
[14:06:28 CDT(-0500)] <Bosmon2> Do you have some other candidates?
[14:06:34 CDT(-0500)] <Bosmon2> I mean, for XHR mocking
[14:06:38 CDT(-0500)] <Bosmon2> Not for GSoC
[14:06:49 CDT(-0500)] <colinclark> greggy: Can you tell Aviper the specific next steps for applying to our GSoC projects?
[14:06:55 CDT(-0500)] <colinclark> Bosmon2: Hang on one sec, sorry
[14:07:05 CDT(-0500)] <Aviper> aah
[14:07:07 CDT(-0500)] <Bosmon2> Sorry, I'll bbiab
[14:07:17 CDT(-0500)] <colinclark> ok
[14:07:21 CDT(-0500)] <Aviper> colinclark: i have come up a draft proposal probably you can just skim it and just give a feedback
[14:07:27 CDT(-0500)] <colinclark> sure, that's great
[14:07:33 CDT(-0500)] <colinclark> Aviper: would you like to email it to me?
[14:07:43 CDT(-0500)] <Aviper> ohh yaa i suppose it was forwarded to you
[14:07:48 CDT(-0500)] <Aviper> idk i will do it now
[14:07:55 CDT(-0500)] <colinclark> Ah, perfect. Let me check!
[14:08:47 CDT(-0500)] <Bosmon2> Nice demo, Aviper
[14:08:58 CDT(-0500)] <Aviper> thanxx
[14:09:15 CDT(-0500)] <Aviper> well i thought to try things out before applying and to get a headstart
[14:09:32 CDT(-0500)] <Aviper>
[14:09:36 CDT(-0500)] <Bosmon2> I didn't realise that all of that "flow control" stuff was actually part of the player and not the media element
[14:09:44 CDT(-0500)] <Bosmon2> It behaves strangely when failing to get data from Google India's servers
[14:10:23 CDT(-0500)] <Aviper> aah yaa
[14:10:36 CDT(-0500)] <Aviper> :/
[14:11:24 CDT(-0500)] <Bosmon2> Or perhaps this is just something to do with Chrome's support for HTML 5 video...
[14:11:40 CDT(-0500)] <Bosmon2> Do you know if the different HTML 5 implementations behave differently?
[14:11:59 CDT(-0500)] <colinclark> Bosmon2: Did Chrome maybe drop Theora support or something?
[14:12:04 CDT(-0500)] <colinclark> In their efforts to promote WebM?
[14:12:08 CDT(-0500)] <Aviper> well … chrome actually supports mp4 and webm
[14:12:09 CDT(-0500)] <Aviper> yaa
[14:12:17 CDT(-0500)] <Bosmon2> I'm not sure - the video certainly plays well, when there is data
[14:12:23 CDT(-0500)] <Aviper> i chked them on Ogg and mp4 on firefox and safari
[14:12:26 CDT(-0500)] <Aviper> did okayy on that
[14:12:28 CDT(-0500)] <Bosmon2> But when there is not data, rather than stopping and buffering, it seems to keep trying
[14:12:28 CDT(-0500)] <colinclark> Aviper: They actually recently dropped H.264 (mp4) format, I think
[14:12:41 CDT(-0500)] <Bosmon2> And often circles over the same few set of frames whilst it is waiting for data
[14:12:45 CDT(-0500)] <Aviper> aah… soo its all WebM promotion then
[14:13:05 CDT(-0500)] <Bosmon2> I'll try Firefox...
[14:13:06 CDT(-0500)] <colinclark> Bosmon2, Aviper: It works in my Mac copy of Chrome
[14:13:08 CDT(-0500)] <colinclark> so I think it's fine
[14:13:19 CDT(-0500)] <Aviper> aah mac (Y)
[14:13:26 CDT(-0500)] <Bosmon2> colinclark: But perhaps that's because you're getting good data flow?
[14:13:31 CDT(-0500)] <colinclark> perhaps, yes
[14:13:33 CDT(-0500)] <Aviper> yaa that can be
[14:13:38 CDT(-0500)] <colinclark> Okay, so Aviper I'll take a look at your project proposal and give you some feedback if I have any
[14:13:49 CDT(-0500)] <colinclark> In the meantime, you can feel free to follow the usual application process
[14:13:51 CDT(-0500)] <Aviper> aah thanx… that would be helpful...
[14:13:59 CDT(-0500)] <colinclark> Google tells us how many spots we get
[14:14:06 CDT(-0500)] <colinclark> but hopefully it all works out and we can work with you!
[14:14:19 CDT(-0500)] <Aviper> thanx… i am indeed eager...
[14:14:42 CDT(-0500)] <Aviper> to help out even after gsoc
[14:14:55 CDT(-0500)] <Bosmon2> That's awesome, Aviper
[14:15:02 CDT(-0500)] <colinclark> cool
[14:15:05 CDT(-0500)] <Bosmon2> HTML 5 video is a crucial and rapidly developing area
[14:15:10 CDT(-0500)] <Bosmon2> Lots of interesting work to be done there...
[14:15:13 CDT(-0500)] <colinclark> Best of luck with the application process, Aviper.
[14:15:25 CDT(-0500)] <Aviper> aah thanx
[14:15:30 CDT(-0500)] <Aviper> one thing is… i checked out the current video component present…
[14:15:35 CDT(-0500)] <Aviper> in Fluid infusion
[14:15:41 CDT(-0500)] <Aviper> it was worked upon before
[14:15:48 CDT(-0500)] <Bosmon2> Hmm... in Firefox, the video never seems to get behind
[14:15:55 CDT(-0500)] <Bosmon2> So perhaps it is just buggy flow control in my Chrome
[14:15:56 CDT(-0500)] <Aviper> aah !
[14:17:44 CDT(-0500)] <Bosmon2> Well, nice demo, Aviper - and interesting use of a "microformat"
[14:18:21 CDT(-0500)] <Aviper> yaa those were a part of my proposal
[14:18:59 CDT(-0500)] <Aviper> and really am working out more on having a logical way thu them
[14:19:08 CDT(-0500)] <Aviper>
[14:19:19 CDT(-0500)] <Aviper> hope things turn out well
[14:19:28 CDT(-0500)] <Bosmon2> I hope so too
[14:19:29 CDT(-0500)] <Aviper> will come up with more soon !!
[14:19:48 CDT(-0500)] <Bosmon2> On some considerations, a format based on JSON would be more stable and portable
[14:19:57 CDT(-0500)] <Bosmon2> But there are some difficulties on that side too
[14:20:07 CDT(-0500)] <Bosmon2> "HTML encoded in JSON" is a nasty thing to carry around
[14:20:19 CDT(-0500)] <Bosmon2> And so the microformat approach, at least to start with, offers a better potential for authoring
[14:20:55 CDT(-0500)] <Aviper> yaa …i went thru the Json way of doing it
[14:21:26 CDT(-0500)] <Aviper> actually the current Fluid video component … was tried that way
[14:21:40 CDT(-0500)] <Aviper> but yaa will look upon that part..
[14:21:45 CDT(-0500)] <Aviper> thats really a concern
[14:22:06 CDT(-0500)] <Bosmon2> With the microformat, people could easily "get off the ground" with existing authoring tools... for example, you could imagine someone hacking something together in Dreamweaver
[14:22:14 CDT(-0500)] <Bosmon2> Which probably wouldn't complain too much about the custom tags
[14:22:32 CDT(-0500)] <Bosmon2> But a general JSON package offers the possibility of more interesting "effects"... such as general function calls occuring at the sync points
[14:23:18 CDT(-0500)] <Aviper> aaah … thats really a point i will research more...
[14:23:24 CDT(-0500)] <Aviper> hmm
[14:23:32 CDT(-0500)] <Aviper> thanx to point out that
[14:23:39 CDT(-0500)] <Bosmon2> So for example, my father makes tapes about chess
[14:23:48 CDT(-0500)] <Bosmon2> One application I considered, was a video stream with embedded markers...
[14:23:59 CDT(-0500)] <Bosmon2> Now, there are lots of Javascript chess board apps out there
[14:24:16 CDT(-0500)] <Bosmon2> But in this case the effect of the marker would have to be, ultimately, to issue a particular function call to some other embedded piece of the page
[14:24:29 CDT(-0500)] <colinclark> Bosmon2: The caption format our VideoPlayer users currently is JSON
[14:24:42 CDT(-0500)] <colinclark> it's borrowed from heidi_'s internal OpenCaps caption format
[14:24:47 CDT(-0500)] <Bosmon2> Cool
[14:25:00 CDT(-0500)] <colinclark> And we have a "rosetta stone" caption converter
[14:25:04 CDT(-0500)] <Bosmon2> Yes, our initial applications will simply be caption playing and authoring
[14:25:10 CDT(-0500)] <colinclark> that should be able to convert most mainstream captions formats to JSON
[14:25:18 CDT(-0500)] <Bosmon2> But it is interesting to consider this task within the general context of "media synchronised effects"
[14:25:32 CDT(-0500)] <colinclark> yes
[14:25:48 CDT(-0500)] <colinclark> The goal for the this project will be to synchronize other stuff--especially audio descriptions and transcripts
[14:25:51 CDT(-0500)] <Bosmon2> For example, a media player that issues suitably encoded IoC blocks at the rest of the page, from time to time
[14:26:00 CDT(-0500)] <colinclark> but there is a Mozilla Drumbeat project that has been catching a lot of attention, Popcorn.js
[14:26:13 CDT(-0500)] <colinclark> which is a sort of interesting but monolithic attempt to synchronize almost anything to a video
[14:26:22 CDT(-0500)] <colinclark> which is cool
[14:26:30 CDT(-0500)] <Aviper> yaa
[14:26:36 CDT(-0500)] <Bosmon2> Interesting
[14:26:39 CDT(-0500)] <Bosmon2> They seem to be mainly XML-heads
[14:26:44 CDT(-0500)] <Aviper> the popcorn.js by drumbeat is really good
[14:27:13 CDT(-0500)] <colinclark> Hopefully we'll have an opportunity to collaborate with them at some point
[14:27:31 CDT(-0500)] <Aviper> aah
[14:27:38 CDT(-0500)] <colinclark> I think audio description syncing will probably be the coolest part of this project
[14:27:51 CDT(-0500)] <Bosmon2> Certainly, the most immediately productive
[14:27:53 CDT(-0500)] <colinclark> really useful for making videos more usable for people who can't see the video track
[14:28:11 CDT(-0500)] <Bosmon2> And as we know, productivity is what is really "cool"
[14:28:32 CDT(-0500)] <colinclark>
[14:28:37 CDT(-0500)] <colinclark> Okay, so Bosmon2 and mlam
[14:28:47 CDT(-0500)] <colinclark> Should we chat about mocking our use of XHR in Uploader?
[14:28:55 CDT(-0500)] <mlam> Sure
[14:29:44 CDT(-0500)] <colinclark> So, I just read above
[14:30:00 CDT(-0500)] <colinclark> michelled: you and boz were suggesting extending Mockjax to support file uploads?
[14:30:06 CDT(-0500)] <colinclark> I'd like to do that
[14:30:11 CDT(-0500)] <Bosmon2> I think it was just me
[14:30:12 CDT(-0500)] <colinclark> It would mean another change I wanted to do
[14:30:22 CDT(-0500)] <colinclark> Which is to add support for file uploads to jQuery.ajax()
[14:30:25 CDT(-0500)] <colinclark> would it not?
[14:30:32 CDT(-0500)] <Bosmon2> michelled - did you want another plan?
[14:30:43 CDT(-0500)] <michelled> um, I mentioned it didn't support file uploads and then got distracted by cspace
[14:30:53 CDT(-0500)] <colinclark> We use a raw XHR, since jQuery has no way for us to pass along the file data itself
[14:31:14 CDT(-0500)] <Bosmon2> Ah, that's interesting
[14:31:16 CDT(-0500)] <colinclark> Bosmon2: Am I correct that Mockjax is a stub of jQuery.ajax()?
[14:31:19 CDT(-0500)] <Bosmon2> That would be a nice contribution to both communities
[14:31:23 CDT(-0500)] <Bosmon2> colinclark - that's right
[14:31:23 CDT(-0500)] <colinclark> Fish and I were reading the code this morning
[14:31:25 CDT(-0500)] <colinclark> cool
[14:31:32 CDT(-0500)] <colinclark> I guess that was a sort of Socratic question
[14:31:36 CDT(-0500)] <colinclark> I need to get out of the habit
[14:31:40 CDT(-0500)] <Bosmon2> I don't think so
[14:31:41 CDT(-0500)] <colinclark> Okay, so
[14:31:46 CDT(-0500)] <Bosmon2> Socratic Learning is probably the best kind
[14:31:47 CDT(-0500)] <colinclark> Right now, we use a raw XHR
[14:31:49 CDT(-0500)] <colinclark> lol
[14:31:57 CDT(-0500)] <Bosmon2> "Yes, Socrates, what you say is quite right"
[14:31:59 CDT(-0500)] <Bosmon2> "Very so"
[14:32:30 CDT(-0500)] <colinclark> lol
[14:32:39 CDT(-0500)] <Bosmon2> And I guess we face exactly the same tasks within Node.js too
[14:32:49 CDT(-0500)] <colinclark> So, we use two features of XHR that aren't available via jQuery.ajax() yet
[14:33:09 CDT(-0500)] <colinclark> The ability to specify a FormData object to xhr.send()
[14:33:30 CDT(-0500)] <colinclark> and the xhr.sendAsBinary() method
[14:33:50 CDT(-0500)] <Bosmon2> Should be quite straightforward, I imagine
[14:33:58 CDT(-0500)] <colinclark> I don't remember if jQuery.ajax() supports setting request headers?
[14:34:01 CDT(-0500)] <Bosmon2> There's nothing "special" about the new XHRs in terms of progress indication?
[14:34:04 CDT(-0500)] <Bosmon2> Yes, it does
[14:34:10 CDT(-0500)] <colinclark> Bosmon2: Yes, there's that, too
[14:34:24 CDT(-0500)] <Bosmon2> I assume they just use the existing readyState system
[14:34:35 CDT(-0500)] <colinclark> no
[14:34:38 CDT(-0500)] <colinclark> XHR level 2 specifies an upload property
[14:34:39 CDT(-0500)] <Bosmon2> oh
[14:34:44 CDT(-0500)] <colinclark> which has an onprogress event
[14:34:50 CDT(-0500)] <Bosmon2> That is a bit awkward
[14:34:56 CDT(-0500)] <colinclark> it is, yes
[14:35:19 CDT(-0500)] <colinclark> So the question is, should we do this?
[14:35:24 CDT(-0500)] <colinclark> Where "this" is defined as:
[14:35:34 CDT(-0500)] <colinclark> 1. Adding support for sendAsBinary and FormData
[14:35:41 CDT(-0500)] <colinclark> 2. Adding progress event support
[14:35:45 CDT(-0500)] <colinclark> to jQuery.ajax()
[14:35:50 CDT(-0500)] <colinclark> and to Mockjax as well
[14:35:59 CDT(-0500)] <colinclark> It has always been on our to-do list
[14:36:08 CDT(-0500)] <colinclark> the question is how high up on the list we want it to be
[14:36:10 CDT(-0500)] <Bosmon2> Yes
[14:36:14 CDT(-0500)] <Bosmon2> This is a great question
[14:36:23 CDT(-0500)] <Bosmon2> What is our "Plan B" if we decided not to do this?
[14:36:41 CDT(-0500)] <colinclark> Find another mock ajax library and add #1 and #2 to it
[14:36:43 CDT(-0500)] <colinclark> or make our own
[14:36:48 CDT(-0500)] <colinclark> neither seems like a great investment
[14:37:06 CDT(-0500)] <colinclark> in other words, 99% of our Ajax usage goes through jQuery.ajax()
[14:37:07 CDT(-0500)] <Bosmon2> mockjax seemed the best such framework I found in my trawl... but this was already a few months ago now
[14:37:11 CDT(-0500)] <Bosmon2> These things change very fast
[14:37:25 CDT(-0500)] <Bosmon2> Would it be worth making another sweep?
[14:37:33 CDT(-0500)] <colinclark> Sure
[14:37:45 CDT(-0500)] <colinclark> Bosmon2: Does it makes sense for you to do so, since you're most recently familiar with the options
[14:37:51 CDT(-0500)] <colinclark> Last time I looked at them was 2008
[14:37:53 CDT(-0500)] <colinclark>
[14:37:54 CDT(-0500)] <Bosmon2> ok
[14:37:57 CDT(-0500)] <Bosmon2> I will have another look
[14:37:59 CDT(-0500)] <colinclark> Thanks
[14:38:04 CDT(-0500)] <Bosmon2> 1. looks pretty easy
[14:38:12 CDT(-0500)] <colinclark> I figure adding support to jQuery would take me a couple days in total? Something like that
[14:38:26 CDT(-0500)] <Bosmon2> But 2. might imagine creating some kind of "new idiom"... or else doing something bare like just exposing the onProgress directly
[14:38:37 CDT(-0500)] <Bosmon2> I guess there is no point creating new abstractions for these things unless it is necessary
[14:38:51 CDT(-0500)] <colinclark> I guess it would have to mirror jQuery's current abstraction for similar callbacks
[14:38:53 CDT(-0500)] <Bosmon2> What support does IE9 have for this HTML 5 API?
[14:38:58 CDT(-0500)] <colinclark> NONE
[14:39:00 CDT(-0500)] <colinclark> jerks
[14:39:02 CDT(-0500)] <colinclark>
[14:39:03 CDT(-0500)] <Bosmon2> super
[14:39:10 CDT(-0500)] <Bosmon2> And what do they have in its place.....
[14:39:12 CDT(-0500)] <colinclark> Nothing
[14:39:15 CDT(-0500)] <Bosmon2> ....
[14:39:18 CDT(-0500)] <Bosmon2> "Not an electronic sausage"
[14:39:19 CDT(-0500)] <colinclark> Flash
[14:39:26 CDT(-0500)] <Bosmon2> Astounding
[14:39:32 CDT(-0500)] <colinclark> Have you seen Paul Rouget's IE9 page, Bosmon2?
[14:39:38 CDT(-0500)] <colinclark> I sent it around a month or so ago
[14:39:39 CDT(-0500)] <colinclark> pretty funny
[14:39:42 CDT(-0500)] <colinclark> let me dig it up
[14:39:45 CDT(-0500)] <Bosmon2> OK, so we are stuck maintaining our Flash configuration of the uploader for the forseeable future then
[14:39:50 CDT(-0500)] <Bosmon2> It is "vital"
[14:40:05 CDT(-0500)] <colinclark> http://people.mozilla.com/~prouget/ie9/ie9_vs_fx4.html
[14:40:12 CDT(-0500)] <colinclark> Bosmon2: Until we drop IE support, yes
[14:40:27 CDT(-0500)] <colinclark> It's essentially deprecated on all non-IE browsers
[14:40:39 CDT(-0500)] <Bosmon2> ok
[14:40:46 CDT(-0500)] <colinclark> and there's the steep caveat that IE users will experience all of the accessibility and usability problems associated with SWFUpload
[14:40:49 CDT(-0500)] <Bosmon2> Microsoft really should stop trying to make their own browser
[14:40:53 CDT(-0500)] <colinclark> but the nice thing is that there is a clear path to resolving it
[14:41:00 CDT(-0500)] <Bosmon2> They've been amply proven to be no good at it
[14:41:06 CDT(-0500)] <colinclark> i.e. the installation of Firefox, Chrome, Opera, or Safari
[14:41:15 CDT(-0500)] <Bosmon2> I imagine most AT users use Firefox anyway?
[14:41:16 CDT(-0500)] <colinclark> Bosmon2: They're taking a lot of flak for not supporting XP
[14:41:20 CDT(-0500)] <colinclark> which is entirely apt
[14:41:24 CDT(-0500)] <colinclark> Well, that's an interesting question
[14:41:25 CDT(-0500)] <Bosmon2> This seemed to be what we discovered in our round of testing for 1.3
[14:41:37 CDT(-0500)] <colinclark> I think in reality many AT users still use IE6 and old versions of JAWS
[14:42:05 CDT(-0500)] <colinclark> But "progressive" AT users are increasingly switching to Firefox, as best as I can tell
[14:42:17 CDT(-0500)] <Bosmon2> Oh wow, FF4 supports drag and drop from the desktop
[14:42:18 CDT(-0500)] <Bosmon2> Superb
[14:42:23 CDT(-0500)] <colinclark> yes
[14:42:30 CDT(-0500)] <colinclark> a feature we can some day add to the Uploader
[14:42:42 CDT(-0500)] <Bosmon2> I would use that
[14:42:45 CDT(-0500)] <Bosmon2> I hate file dialogs
[14:42:55 CDT(-0500)] <colinclark> Bosmon2: No wonder, you use Windows
[14:42:56 CDT(-0500)] <Bosmon2> Especially given the size of my file system
[14:43:09 CDT(-0500)] <Bosmon2> I hate Mac file dialogs even more
[14:43:16 CDT(-0500)] <colinclark>
[14:43:34 CDT(-0500)] <colinclark> Okay, so we have some next steps
[14:43:38 CDT(-0500)] <Bosmon2> Anyway, so, our action point 1 is for me to assess any alternatives to MockJax
[14:43:41 CDT(-0500)] <colinclark> yes
[14:43:49 CDT(-0500)] <Bosmon2> And for you to consider models for supporting "onProgress" in jquery.ajax()?
[14:43:56 CDT(-0500)] <colinclark> Sure, I'll do that now
[14:44:14 CDT(-0500)] <colinclark> mlam: For you, write as many tests as you can without needing a mock XHR
[14:44:22 CDT(-0500)] <mlam> Ok
[14:44:23 CDT(-0500)] <colinclark> Which can be pretty comprehensive
[14:44:36 CDT(-0500)] <colinclark> Bosmon2: Can you give mlam any advice on how to test the "join points" of the Uploader?
[14:44:46 CDT(-0500)] <colinclark> In other words, we learned a valuable lesson over the past two weeks
[14:44:48 CDT(-0500)] <colinclark> Relearned?
[14:44:59 CDT(-0500)] <colinclark> That we need integration test coverage
[14:45:01 CDT(-0500)] <Bosmon2> Yes
[14:45:13 CDT(-0500)] <colinclark> which include things like which subcomponents are resolve, with what arguments, etc.
[14:45:23 CDT(-0500)] <colinclark> So, if you were to recommend a next test, what might it look like?
[14:45:36 CDT(-0500)] <Bosmon2> Unit tests are very cool, to pinpoint failures in drifts in contract etc.
[14:45:43 CDT(-0500)] <Bosmon2> But getting "overall coverage" is a greater priority
[14:46:03 CDT(-0500)] <Bosmon2> The next test should look like something which can actually instantiate fluid.uploader() in some kind of reasonably realistic configuration from an automated test case
[14:46:19 CDT(-0500)] <Bosmon2> So at the moment I am "shoe-horning" tests into our demo page
[14:46:25 CDT(-0500)] <Bosmon2> Which anastasiac already informed me is inappropriate
[14:46:26 CDT(-0500)] <colinclark> Okay
[14:46:29 CDT(-0500)] <Bosmon2> There are "three different buttons"
[14:46:35 CDT(-0500)] <colinclark> eek
[14:46:37 CDT(-0500)] <Bosmon2> Which test 3 different integration scenarios for the Uploader
[14:46:43 CDT(-0500)] <colinclark> I'm sure our demos team will shudder at that news
[14:46:45 CDT(-0500)] <colinclark>
[14:46:48 CDT(-0500)] <Bosmon2> All of these should go away, and the old demo should be restored
[14:46:49 CDT(-0500)] <colinclark> but it makes sense for now
[14:47:03 CDT(-0500)] <Bosmon2> And they should be replaced by three perfectly normal jQuery test cases
[14:47:11 CDT(-0500)] <Bosmon2> jqUnit
[14:47:11 CDT(-0500)] <colinclark> So, in other words, a test that instantiates, say, an "HTML5 Uploader"
[14:47:24 CDT(-0500)] <Bosmon2> Yes
[14:47:29 CDT(-0500)] <Bosmon2> Very appropriate use of quotation marks
[14:47:33 CDT(-0500)] <colinclark> and asserts that it was successful, i.e. it has a FileQueueView, the correct remotes, etc.
[14:47:40 CDT(-0500)] <Bosmon2> That is, "The configuration of the Uploader as for HTML5"
[14:47:50 CDT(-0500)] <Bosmon2> Clearly this test case cannot touch any actual HTML 5 features
[14:47:55 CDT(-0500)] <colinclark> It speaks to that interesting issue you hit last week, mlam
[14:48:06 CDT(-0500)] <colinclark> Where you changed an apparently mis-typed demands block
[14:48:18 CDT(-0500)] <colinclark> "fluid.uploader.remote" to "fluid.uploader.html5Strategy.remote"
[14:48:20 CDT(-0500)] <Bosmon2> Otherwise it would fail to be usable as an automated test case on many browsers
[14:48:21 CDT(-0500)] <mlam> Yes, so would it be ideal to have empty components?
[14:48:35 CDT(-0500)] <Bosmon2> Well, we would like to test "as much of the codebase as possible"
[14:48:38 CDT(-0500)] <colinclark> mlam: It should actual have real component, rather than empty components
[14:48:46 CDT(-0500)] <Bosmon2> Which is the main reason we are thinking of strategies for XHR mocks
[14:48:56 CDT(-0500)] <Bosmon2> But it might be possible to test less of the component, with simpler mocks, yes
[14:49:21 CDT(-0500)] <Bosmon2> Ideally the code under test would "extend as far towards the bare metal as possible"
[14:49:32 CDT(-0500)] <colinclark> right
[14:49:34 CDT(-0500)] <Bosmon2> That is, towards the bare metal consisting of the HTML5 api, and a live server operating HTTP
[14:49:57 CDT(-0500)] <colinclark> So, mlam, do you think you're equipped to write a test against the whole uploader, in its two different configurations?
[14:50:13 CDT(-0500)] <mlam> Yah, I can definitely give it a shot.
[14:50:27 CDT(-0500)] <Bosmon2> Really, with orthogonality, we have "6 different configurations" now
[14:50:39 CDT(-0500)] <colinclark> can you outline the 6, just so we're clear?
[14:50:45 CDT(-0500)] <Bosmon2> There are the 2 different base implementations, HTML5 and SWF, and then 3 different "integration scenarios" orthogonal to them
[14:50:49 CDT(-0500)] <Bosmon2> Which are tested by my 3 buttons
[14:51:03 CDT(-0500)] <Bosmon2> i) direct function call, ii) IoC configuration delivered via defaults, iii) IoC configuration delivered via demands
[14:52:14 CDT(-0500)] <Bosmon2> And no doubt more of these will arise, as we discover more crazy edge cases
[14:52:32 CDT(-0500)] <Bosmon2> Javascript testing discipline makes it unnaturally easy to test across these kinds of orthogonal spaces by just using nested loops
[15:00:04 CDT(-0500)] <colinclark> So mlam is that enough to take a stab at?
[15:00:46 CDT(-0500)] <mlam> Yup, for sure. so colinclark, once our other components start using IoC, they should all have these sorts of tests as well?
[15:00:52 CDT(-0500)] <colinclark> yes
[15:01:03 CDT(-0500)] <colinclark> yura_: You write a lot of tests like this, right?
[15:02:05 CDT(-0500)] <Bosmon2> One of the big advantages of IoC is that it facilitates creating "test surfaces" like this... just declaratively
[15:02:17 CDT(-0500)] <yura_> mlam: colinclark ya, i have some examples of tests using component as a standalone and through IOC
[15:02:27 CDT(-0500)] <Bosmon2> In theory, every line you can draw around a bunch of components in an IoC tree could form a test surface
[15:02:45 CDT(-0500)] <mlam> is the end of this week still feasible, colinclark?
[15:02:52 CDT(-0500)] <Bosmon2> There is a talk coming up at the NodeConf in May which seems to be explaining "why integration tests suck"
[15:03:09 CDT(-0500)] <Bosmon2> but mainly integration tests suck because they can't take advantage of configuration in this way
[15:03:29 CDT(-0500)] <Bosmon2> OTHER people, when they write integration tests, have to write new code for each new configuration which is tested
[15:03:35 CDT(-0500)] <Bosmon2> So they tend not to write very many of them
[15:03:41 CDT(-0500)] <colinclark> mlam: Do you think it's feasible?
[15:03:58 CDT(-0500)] <colinclark> If it's not, that's okay
[15:04:00 CDT(-0500)] <colinclark> you tell me
[15:05:28 CDT(-0500)] <mlam> I think I can get this component testing done, but i'm not sure about the xhr mocking stuff since you estimate a couple days to get the ajax library to our liking?
[15:06:36 CDT(-0500)] <colinclark> Bosmon2: Do you figure you and I can take care of the xhr mocking, one way or another?
[15:06:41 CDT(-0500)] <Bosmon2> Yes, I think so
[15:07:11 CDT(-0500)] <colinclark> ok
[15:07:12 CDT(-0500)] <Bosmon2> Are we planning to start working against a patched version of jQuery for a while, or do you think there may be a way to make the improvements "at a distance"?
[15:07:12 CDT(-0500)] <colinclark> let's do it
[15:07:14 CDT(-0500)] <mlam> Then yes, I think this week is feasible.
[15:07:20 CDT(-0500)] <Bosmon2> And if so, are we waiting on the 1.5.1 upgrade?
[15:07:58 CDT(-0500)] <colinclark> Bosmon2: That's a good question
[15:08:12 CDT(-0500)] <colinclark> I guess we can either make a plugin or a pull request
[15:09:30 CDT(-0500)] <Bosmon2> Perhaps we can just "opportunistically" do the 1.5.1 upgrade today? It didn't seem like there were many issues left
[15:09:45 CDT(-0500)] <Bosmon2> We should be able to convert all uses of $.value into calls to fluid.value now
[15:09:47 CDT(-0500)] <Bosmon2> $.val
[15:11:12 CDT(-0500)] <Justin_o> Bosmon2: are we sure that's the only issue?
[15:16:27 CDT(-0500)] <Bosmon2> There are some others
[15:16:49 CDT(-0500)] <Bosmon2> But that seemed to be the most widespread one, from jkkremer's report
[15:30:56 CDT(-0500)] <Justin_o> Bosmon2: i'm not sure jkkremer has made it through finding all the issues or not.. I think he'll be in on Friday though, so we can probably double check with him then. I think he'll also check e-mails before then if we really need to know right away

Browser not supported