[08:04:55 CDT(-0500)] <Justin_o> jhung, cindyli: I've updated the planning page with the high level info that jhung and I talked about yesterday afternoon http://wiki.fluidproject.org/display/fluid/Decapod+0.7+Planning
[08:05:12 CDT(-0500)] <cindyli> thanks, Justin_o
[08:11:25 CDT(-0500)] <jhung> thanks justin_o. Given the scope of this release, I was wondering if it made more sense to do 2 week iterations.
[08:11:46 CDT(-0500)] <Justin_o> jhung: when do we want to finish by?
[08:12:08 CDT(-0500)] <jhung> end of October?
[08:12:58 CDT(-0500)] <Justin_o> jhung: so if we say that's Nov 2 that will give us 8 weeks
[08:13:07 CDT(-0500)] <Justin_o> not counting today of course
[08:13:34 CDT(-0500)] <jhung> yeah. :/
[08:13:58 CDT(-0500)] <jhung> Well I guess we can go through planning and then see what we need to do justin_o, cindyli
[08:14:47 CDT(-0500)] <Justin_o> jhung: makes sense.. when would you like to do that
[08:14:49 CDT(-0500)] <jhung> Let's start with 1 week chunks to start
[08:15:01 CDT(-0500)] <Justin_o> jhung: sure… that might make sense..
[08:15:38 CDT(-0500)] <jhung> I'm going to put in tables for the whole release and then we can fill it in.
[08:16:06 CDT(-0500)] <Justin_o> jhung: okay
[08:21:12 CDT(-0500)] <jhung> justin_o, cindyli, I've updated the planning page.
[08:21:28 CDT(-0500)] <cindyli> ok, thanks
[08:22:08 CDT(-0500)] <jhung> Justin_o, Cindyli, here's what I'm thinking...
[08:22:25 CDT(-0500)] <jhung> Week 1: Capture server, Capture UI design
[08:22:56 CDT(-0500)] <jhung> Week 2: Capture UI development, Stereo Dewarp testing, Stereo dewarp UI design.
[08:23:14 CDT(-0500)] <jhung> Week 3: Stereo Dewarp UI development.
[08:23:48 CDT(-0500)] <jhung> Rather, Weeks would likely be longer than 1 week.
[08:24:31 CDT(-0500)] <jhung> Forgot about calibration too. :/ that'll add another week.
[08:42:07 CDT(-0500)] <Justin_o> jhung: when you say capture ui development in week 2.. is that the real design? or just something to test with?
[08:44:25 CDT(-0500)] <jhung> real design justin_o. Let's call it "Iteration 2" instead of week since I don't think we can do "Week 1" in 1 week. 
[08:45:17 CDT(-0500)] <Justin_o> jhung: yep.. makes sense.. better to call them interations
[08:46:33 CDT(-0500)] <jhung> Iteration 3 should also include Dewarp server development justin_o and cindyli
[08:47:39 CDT(-0500)] <Justin_o> jhung: okay.. and we will need some time to work on bug fixes and updates (example error handling) for export too
[08:47:57 CDT(-0500)] <jhung> yeah.
[08:53:51 CDT(-0500)] <jhung> So iteration 5 will be bug fixing, UI enhancements, configuration UI. Iteration 6 will be testing, documentation, and release.
[08:54:00 CDT(-0500)] <jhung> ^justin_o, cindyli
[08:54:37 CDT(-0500)] <Justin_o> jhung: okay
[09:08:51 CDT(-0500)] <jhung> justin_o, cindyli - how important is the Decapod configuration feature?
[09:10:05 CDT(-0500)] <Justin_o> jhung: hmm… well then can configure it still, but it won't be as easy.. will need some minor technical know how.. i suppose if we document it well, it won't be too bad… but i think the units setting will definitely be much more difficult
[09:12:11 CDT(-0500)] <jhung> hmmm… okay justin_o. I'm thinking that since we have to write documentation anyway, maybe we put the config UI out of this release. I think we're going to have our hands full. We're not even factoring the overhead if we find bugs in Genpdf, Stereo, and Calibration
[09:12:39 CDT(-0500)] <Justin_o> jhung: sure.. makes sense.. if we have time we can come back to it
[09:12:47 CDT(-0500)] <jhung> cool.
[09:13:00 CDT(-0500)] <Justin_o> jhung: when do you want to start tasking this out?
[09:15:05 CDT(-0500)] <jhung> Maybe this afternoon? This will give Cindyli some time to wrap up atutor work?
[09:15:45 CDT(-0500)] <cindyli> getting close to finish up atutor work. will let you know, jhung & Justin_o
[09:16:02 CDT(-0500)] <jhung> thanks cindyli
[09:16:10 CDT(-0500)] <cindyli> np
[09:17:16 CDT(-0500)] <jhung> justin_o, in the meantime maybe you can start writing up a spec for the camera controller?
[09:17:39 CDT(-0500)] <jhung> unless you're in the middle of something of course. 
[09:17:43 CDT(-0500)] <Justin_o> jhung: okay.. i'll try to think of something for that.. you mean the server spec right?
[09:18:14 CDT(-0500)] <jhung> yeah. Or maybe wait to collab w cindyli. It's your choice.
[09:22:21 CDT(-0500)] <Justin_o> jhung: okay… maybe i'll start something and then work it out cindyli
[09:36:51 CDT(-0500)] <cindyli> jhung & Justin_o, i'm back on decapod. time to task out the iteration plan?
[09:37:45 CDT(-0500)] <Justin_o> cindyli, jhung: i can start now.. or jhung if you aren't ready yet cindyli and I can start talking about the code
[09:37:45 CDT(-0500)] <jhung> cindyli, justin_o: great. Let me wrap up my edits to the planning page and then we can chat?
[09:37:55 CDT(-0500)] <Justin_o> jhung: how long will you be?
[09:37:57 CDT(-0500)] <jhung> I'll be ready shortly.
[09:38:05 CDT(-0500)] <Justin_o> jhung: okay.. then we can wait for you
[09:40:04 CDT(-0500)] <Justin_o> jhung: question, for now are we assuming that the calibration will only be for stereo
[09:40:12 CDT(-0500)] <jhung> cindyli and justin_o: refresh the page. Cindy I will join you
[09:40:18 CDT(-0500)] <jhung> justin_o: yes for now.
[09:40:18 CDT(-0500)] <cindyli> sure
[09:41:19 CDT(-0500)] <cindyli> Justin_o: we are going to collab room so we can talk freely with skype
[09:41:39 CDT(-0500)] <Justin_o> cindyli: thanks..logging into Skype now
[10:11:15 CDT(-0500)] <yura1> hey Justin_o
[10:11:26 CDT(-0500)] <Justin_o> yura1: hello
[10:11:40 CDT(-0500)] <yura> quick question to you
[10:12:00 CDT(-0500)] <Justin_o> yura: sure
[10:12:01 CDT(-0500)] <yura> Justin_o: was there some utility to lookup a decorator component that you were using?
[10:12:21 CDT(-0500)] <Justin_o> yes.. i'm trying to remember the name.. one second
[10:13:04 CDT(-0500)] <Justin_o> fluid.renderer.getDecoratorComponents
[10:13:06 CDT(-0500)] <Justin_o> yura: ^
[10:13:15 CDT(-0500)] <Justin_o> i think it's in the rendererUtilities file
[10:13:17 CDT(-0500)] <yura> Justin_o: thanks
[10:13:24 CDT(-0500)] <yura> that's the one needs instantiator now ?
[10:13:25 CDT(-0500)] <Justin_o> it takes the component and the instantiator as arguments
[10:13:29 CDT(-0500)] <Justin_o> yura: yep
[10:14:21 CDT(-0500)] <Justin_o> yura: i believe it returns an array of all the decorator components
[10:14:28 CDT(-0500)] <yura> not in my version 
[10:57:42 CDT(-0500)] <colinclark> hey michelled and alexn
[10:58:00 CDT(-0500)] <colinclark> I was curious about your thoughts based on what we were discussing yesterday evening in the channel
[10:58:08 CDT(-0500)] <colinclark> Summarized here: https://github.com/fluid-project/videoPlayer/pull/45/files
[10:58:23 CDT(-0500)] <colinclark> In short, I noticed three things about this particular implementation
[10:58:41 CDT(-0500)] <colinclark> 1. Its supporting infrastructure has a lot of TODO comments around it, suggesting that it needs some attention
[10:59:19 CDT(-0500)] <colinclark> 2. The feature detection code is well-factored, using components in the static environment to provide IoC-resolvable information about browser features such as if full screen mode is supported
[10:59:49 CDT(-0500)] <colinclark> 3. The Video Player is well subcomponentized, meaning it should be straightforward to add or remove the full screen toggle button based on this context information
[11:00:38 CDT(-0500)] <colinclark> The key question being, why do we instantiate the full screen toggle button and then go back and hide in CSS if it's not supported, as opposed to using a demands block to elide it completely prior to instantiation?
[11:00:50 CDT(-0500)] <colinclark> And I guess it's worth considering if there are any consequences to this approach
[11:01:01 CDT(-0500)] <colinclark> given that demands blocks are somewhat brittle due to the fact that they can't easily be overriden
[11:01:07 CDT(-0500)] <colinclark> overridden
[11:01:49 CDT(-0500)] <michelled> colinclark: I think it makes sense to do what you're suggesting - just don't make the button at all if we have no full screen
[11:04:38 CDT(-0500)] <alexn> colinclark michelled: agree on this one too. I have one small question though. What are we going to do about this fluid.browser and features blocks?
[11:05:04 CDT(-0500)] <colinclark> What do you think we should do, alexn? Any suggestions?
[11:05:24 CDT(-0500)] <alexn> colinclark: I remember you mentioned that we might want to refactor this out as well...
[11:05:31 CDT(-0500)] <alexn> well… I did not think much about it yet
[11:05:48 CDT(-0500)] <alexn> but first idea which comes in head to make a component which would detect the environment
[11:06:06 CDT(-0500)] <alexn> and set the appropriate flags as html5 supported or hasFullScreen
[11:06:30 CDT(-0500)] <colinclark> Well, I wonder if we really need that
[11:06:31 CDT(-0500)] <alexn> so that other developers could extend it by adding extra bits
[11:06:42 CDT(-0500)] <alexn> or rework some of our implementations there
[11:06:50 CDT(-0500)] <colinclark> since we do indeed have components added to the static environment as a result of feature detection...
[11:07:19 CDT(-0500)] <colinclark> Just searching through the VideoPlayer.js file, I think there's a distinct problem with hasFeature()
[11:07:29 CDT(-0500)] <colinclark> When you think about it, these kinds of tests are all static
[11:07:57 CDT(-0500)] <colinclark> Ideally you check them once, and then use IoC to resolve a set of components that are appropriate for the feature
[11:08:34 CDT(-0500)] <alexn> using demands blocks ?
[11:08:42 CDT(-0500)] <colinclark> yes
[11:08:50 CDT(-0500)] <colinclark> That's the whole point of IoC in Infusion
[11:09:05 CDT(-0500)] <colinclark> to be able to deliver a context-aware different user experience
[11:10:19 CDT(-0500)] <colinclark> So all these checks in the code seem to serve this sort of purpose
[11:10:42 CDT(-0500)] <colinclark> where, for example, we're using this sketchy "isHTML5" check to determine whether or not to deliver certain parts of the user interface
[11:11:04 CDT(-0500)] <colinclark> michelled: The more I think about it and look at the code, the more I think there's a legacy issue here
[11:11:14 CDT(-0500)] <colinclark> And so it raises the strategic question…
[11:11:20 CDT(-0500)] <michelled> yep, we have a lot of legacy issues in this code base
[11:11:24 CDT(-0500)] <colinclark> what's our plan for supporting non-HTML5 browsers?
[11:11:34 CDT(-0500)] <colinclark> I guess you can answer this question best
[11:11:40 CDT(-0500)] <michelled> colinclark: we actually have a branch that's getting close with a start on that
[11:12:30 CDT(-0500)] <michelled> colinclark: I haven't reviewed it yet, but cindyli has been working on using mediaelement.js to get non html5 browser support: https://github.com/cindyli/videoPlayer/tree/FLUID-4775
[11:12:51 CDT(-0500)] <colinclark> ok
[11:12:55 CDT(-0500)] <colinclark> so, our strategy
[11:13:03 CDT(-0500)] <colinclark> i can try to summarize and you can tell me if I've got it
[11:13:16 CDT(-0500)] <colinclark> 1. We intend to support "modern browsers"
[11:13:29 CDT(-0500)] <colinclark> a. Latest Chrome, Firefox, Safari
[11:13:33 CDT(-0500)] <colinclark> b. IE8
[11:13:37 CDT(-0500)] <colinclark> Is that right?
[11:13:48 CDT(-0500)] <michelled> I'd include IE9 in a
[11:13:52 CDT(-0500)] <michelled> and yes, you've got it right
[11:14:10 CDT(-0500)] <colinclark> okay, IE8+
[11:14:29 CDT(-0500)] <michelled> yes
[11:14:41 CDT(-0500)] <colinclark> 2. We are not currently planning any kind of fallback for media that doesn't "implement the HTML5 media element interface"
[11:14:45 CDT(-0500)] <colinclark> To put it nerdily
[11:14:53 CDT(-0500)] <colinclark> #2, put differently...
[11:14:59 CDT(-0500)] <michelled> well, IE8 falls into that category
[11:15:08 CDT(-0500)] <michelled> oh sorry, media!
[11:15:18 CDT(-0500)] <colinclark> a. We're not currently planning to support Flash-based media (i.e. .flv containers)
[11:15:41 CDT(-0500)] <colinclark> b. We're not currently planning to support proprietary video hosting and players (i.e. YouTube and Vimeo)
[11:15:45 CDT(-0500)] <michelled> colinclark: I think we are planning a longer term support for flash based media
[11:15:53 CDT(-0500)] <michelled> but it's so far into the roadmap that I can't even see it yet
[11:16:00 CDT(-0500)] <colinclark> ok
[11:16:07 CDT(-0500)] <colinclark> Do we have any kind of technical plan for that?
[11:16:10 CDT(-0500)] <colinclark> I'm assuming not
[11:16:31 CDT(-0500)] <colinclark> I'd rather just remux .flv files on the server into an m4v container
[11:16:36 CDT(-0500)] <colinclark> but it may not be practical
[11:17:11 CDT(-0500)] <colinclark> c. I guess a side effect of 2a is that we're not currently planning to support streaming media until the HTML5 streaming spec has been implemented
[11:17:30 CDT(-0500)] <michelled> yeah
[11:17:35 CDT(-0500)] <colinclark> ok
[11:17:49 CDT(-0500)] <colinclark> So
[11:18:11 CDT(-0500)] <colinclark> d. We plan to support non HTML5 Media browsers (i.e. IE8) with MediaElement.js
[11:18:25 CDT(-0500)] <colinclark> which is a Flash-based polyfill for the <video> tag
[11:18:58 CDT(-0500)] <michelled> yep
[11:19:03 CDT(-0500)] <colinclark> Anything else I'm missing?
[11:19:55 CDT(-0500)] <michelled> I don't think so. you already know we are currently using Captionator for Track support and will likely move off that over time.
[11:22:06 CDT(-0500)] <colinclark> yup
[11:22:15 CDT(-0500)] <colinclark> So, I guess the question we have to answer...
[11:22:38 CDT(-0500)] <colinclark> What should we do with legacy code that attempts to do other things on non-HTML5 browsers?
[11:23:12 CDT(-0500)] <colinclark> I guess I'd offer up the idea that we should simply remove it all and inject a small "we're sorry"-type message inside the <video> tag
[11:23:17 CDT(-0500)] <colinclark> and leave it at that?
[11:23:22 CDT(-0500)] <colinclark> perhaps that's too aggressive
[11:23:37 CDT(-0500)] <colinclark> but it is always nice to consider taking cut-and-pasted code and simply deleting it 
[11:23:44 CDT(-0500)] <colinclark> such as fluid.hasFeature()
[11:23:52 CDT(-0500)] <michelled> colinclark: I was thinking that it would be ditched once cindyli's branch was in
[11:24:20 CDT(-0500)] <colinclark> That seems prudent in a way
[11:24:33 CDT(-0500)] <colinclark> Make me an argument for why it is more prudent than just throwing out some code
[11:24:35 CDT(-0500)] <colinclark>
[11:26:04 CDT(-0500)] <michelled> so, my argument hinges on something I'm not sure of at this point. We've had a lot of regression happening over the past little while.
[11:26:25 CDT(-0500)] <colinclark> aha
[11:26:28 CDT(-0500)] <colinclark> scary
[11:26:34 CDT(-0500)] <michelled> but, assuming that we currently have some working features in the older browsers, it seems to me that we are better to keep things working while we improve them
[11:26:53 CDT(-0500)] <colinclark> Well, it's sort of fascinating
[11:27:07 CDT(-0500)] <colinclark> This looks to me like a typical use of fluid.hasFeature() in the Video Player:
[11:27:08 CDT(-0500)] <colinclark> https://github.com/fluid-project/videoPlayer/blob/demo/js/VideoPlayer.js#L401-410
[11:27:19 CDT(-0500)] <michelled> if, however, my fears are true and we don't have working code in older browsers - then I feel we should ditch stuff now and simplify our code base
[11:27:21 CDT(-0500)] <colinclark> I'm just coming back into this code base, so I'm probably missing a lot
[11:27:32 CDT(-0500)] <colinclark> you all need to remind me of what I'm missing
[11:27:44 CDT(-0500)] <colinclark> but if I read this particular block correctly, it's really bizarre
[11:28:05 CDT(-0500)] <colinclark> It's checking to see if we're in an HTML5-compatible browser before putting the controls=true attribute on the <video> tag
[11:28:24 CDT(-0500)] <colinclark> but I imagine if we weren't in an HTML5-compatible browser, it would make no difference at all if that attribute were there or not
[11:29:34 CDT(-0500)] <colinclark> It looks to me like the only really meaningful use of hasFeature("fluid.browser.html5") is to fire an "onHTML5BrowserDetected" event
[11:29:47 CDT(-0500)] <colinclark> Which I think could also be accomplished using a demands block
[11:31:11 CDT(-0500)] <colinclark> michelled: What features would we be looking for in an older browser?
[11:31:18 CDT(-0500)] <colinclark> to know if they even work
[11:33:02 CDT(-0500)] <michelled> it's actually not much colinclark and I'm not even convinced it makes sense to factor things they way they are. Originally, the player also supported youtube videos and in older browser that would still work. but it's all very weird - like the player is trying to do all sorts of things that shouldn't be its business
[11:33:18 CDT(-0500)] <colinclark> yes
[11:33:23 CDT(-0500)] <colinclark> that was my fault, in the original factoring
[11:33:40 CDT(-0500)] <colinclark> At the time, I had this notion that our VideoPlayer would end up "wrapping" other players
[11:33:51 CDT(-0500)] <colinclark> More and more, I just get the feeling that we should embrace the future
[11:34:25 CDT(-0500)] <colinclark> And that if we can come up with some kind of server-side remuxer, we might just decide that there is no other type of media except .webm and .m4v
[11:34:39 CDT(-0500)] <colinclark> And that proprietary cloud-service players are just that
[11:34:50 CDT(-0500)] <colinclark> proprietary players that are founded on the idea of "custom branding"
[11:35:21 CDT(-0500)] <michelled> colinclark: what do you think we should do when we integrate with OER Commons for example
[11:35:23 CDT(-0500)] <colinclark> which usually doesn't allow for things like putting our own elegantly-designed jvass and jamesey UI on them
[11:35:35 CDT(-0500)] <michelled> should some videos be in our player and others in the proprietary ones?
[11:35:44 CDT(-0500)] <colinclark> I think it's the only option
[11:35:46 CDT(-0500)] <colinclark> It's interesting...
[11:35:51 CDT(-0500)] <michelled> it's sad
[11:36:08 CDT(-0500)] <colinclark> If only YouTube would let us take their media and present it in our own way
[11:36:18 CDT(-0500)] <michelled> yeah
[11:36:21 CDT(-0500)] <colinclark> A Video Player is only really useful for people who host their own content
[11:36:35 CDT(-0500)] <colinclark> when it comes to YouTube or Vimeo content, we're in their hands
[11:36:44 CDT(-0500)] <michelled> it makes me wonder whether an OER Commons integration even makes sense
[11:36:53 CDT(-0500)] <michelled> I'm going to need to chat with Lisa about that
[11:37:05 CDT(-0500)] <michelled> but from what I've seen, most of the video content is actually on youtube
[11:37:07 CDT(-0500)] <colinclark> I think we probably want to a "universal media" component that will take care of the complexity of embedding diverse media
[11:37:15 CDT(-0500)] <colinclark> yeah, for sure
[11:37:22 CDT(-0500)] <colinclark> why wouldn't you put your OER on YouTube?
[11:37:27 CDT(-0500)] <colinclark> except for the stupid advertisements
[11:37:44 CDT(-0500)] <colinclark> I guess the question we should explore is to what extend we can augment other players
[11:38:04 CDT(-0500)] <colinclark> that's the real answer to your question about "what value does our video player provide to ordinary authors who put their stuff up on YouTube?"
[11:38:24 CDT(-0500)] <colinclark> I guess Universal Subtitles has answered that question for themselves reasonably well
[11:38:53 CDT(-0500)] <michelled> in that they decorate the existing player?
[11:39:56 CDT(-0500)] <alexn> our videoPlayer is more accessible and accessibility is at its core.
[11:40:10 CDT(-0500)] <alexn> just my 2 cents
[11:40:20 CDT(-0500)] <colinclark> michelled: yes
[11:40:41 CDT(-0500)] <colinclark> alexn: Sure, but the key is to bring accessibility to wherever our users are
[11:40:51 CDT(-0500)] <colinclark> As I do a bit of research, things aren't as bleak as I had thought
[11:41:00 CDT(-0500)] <colinclark> YouTube still does support a "chrome less" player
[11:41:08 CDT(-0500)] <colinclark> and it is remarkably chromeless
[11:41:16 CDT(-0500)] <colinclark> Here's a demo: http://songhaysystem.com/samples/youtube-chromeless/
[11:41:23 CDT(-0500)] <colinclark> with a horrendous UI, of course
[11:42:03 CDT(-0500)] <michelled> wow, that's actually great
[11:43:56 CDT(-0500)] <colinclark> yeah
[11:44:12 CDT(-0500)] <colinclark> the thing I'm trying to figure out now is if we can access things like caption or transcript data
[11:45:20 CDT(-0500)] <colinclark> it looks like the YouTube data API can provide us with sufficient metadata about a video
[11:46:45 CDT(-0500)] <colinclark> Anyway, I guess maybe the original VideoPlayer vision isn't too far off
[11:47:22 CDT(-0500)] <colinclark> Where we deliver more or less of our UI based on the context of the media
[11:47:32 CDT(-0500)] <colinclark> and with different strategy depending on the source of the media
[11:47:34 CDT(-0500)] <michelled> right
[11:49:02 CDT(-0500)] <colinclark> Okay, I'm much clearer on this
[11:49:05 CDT(-0500)] <colinclark> So, alexn
[11:49:11 CDT(-0500)] <colinclark> You've got two pull requests ahead of you
[11:49:31 CDT(-0500)] <colinclark> 1. The one we discussed yesterday, where you will not do the feature detection each time VideoPlayer.fullscreen() is invoked
[11:49:47 CDT(-0500)] <alexn> yup
[11:50:14 CDT(-0500)] <colinclark> 2. Another to use a demands block to replace the full screen button with a fluid.emptySubcomponent in the case where the browser doesn't support full screen mode
[11:50:27 CDT(-0500)] <colinclark> Removing that particular usage of fluid.hasFeature()
[11:50:42 CDT(-0500)] <colinclark> the other uses of it, we'll have to do a bit of research to determine if they actually provide us with any value
[11:50:51 CDT(-0500)] <colinclark> so we can remove that code if necessary in a separate issue
[11:51:02 CDT(-0500)] <colinclark> Does that make sense in terms of your next steps, alexn?
[11:51:15 CDT(-0500)] <alexn> colinclark: it does
[11:51:37 CDT(-0500)] <colinclark> wicked