[15:14:57 CST(-0600)] <cindyli> hi, Bosmon, r u there?

[15:18:09 CST(-0600)] <colinclark> michelled: Do you want to fire me the tickets I should code review?

[15:18:24 CST(-0600)] <colinclark> Also, you all might be interested in this new ruling from the FCC regarding accessibility:

[15:18:30 CST(-0600)] <colinclark> "The Commission also adopted rules that require equipment designed to receive or play back video programming (such as televisions, set-top boxes, computers, smartphones, and tablets) to be equipped with built-in closed caption decoder circuitry or capability to display closed-captioned video programming"

[15:19:35 CST(-0600)] <michelled> that's great to hear colinclark

[15:20:04 CST(-0600)] <michelled> colinclark: two pull requests for cindyli: https://github.com/fluid-project/videoPlayer/pull/10

[15:20:15 CST(-0600)] <michelled> and https://github.com/fluid-project/videoPlayer/pull/11

[15:20:36 CST(-0600)] <michelled> from cindyli that is, for you to review

[15:22:52 CST(-0600)] <cindyli>

[15:36:15 CST(-0600)] <Bosmon> Hello, cindyli

[15:37:14 CST(-0600)] <cindyli> i am writing unit tests for this script: https://github.com/cindyli/videoPlayer/blob/FLUID-4559/js/VideoPlayer_media.js

[15:37:39 CST(-0600)] <Bosmon> Oh, good grief!

[15:37:57 CST(-0600)] <Bosmon> What is going on there with the monkey-patching of the builtin window.setInteral?

[15:38:00 CST(-0600)] <Bosmon> interval?

[15:38:16 CST(-0600)] <cindyli> oh, that part has been tested

[15:38:23 CST(-0600)] <cindyli> my question is about https://github.com/cindyli/videoPlayer/blob/FLUID-4559/js/VideoPlayer_media.js#L102-168

[15:38:25 CST(-0600)] <Bosmon> Well, it may have been tested

[15:38:31 CST(-0600)] <cindyli> "may"

[15:38:37 CST(-0600)] <Bosmon> But I see it as a bad practice that should be removed from the impl...

[15:38:41 CST(-0600)] <Bosmon> As soon as we can see our way to it

[15:38:58 CST(-0600)] <Bosmon> Sorry, I know this wasn't your question

[15:39:19 CST(-0600)] <cindyli> that's ok, good to have someone to discuss about this stratege

[15:39:29 CST(-0600)] <cindyli> well, the old way was using a listener on video tag "timeupdate" event

[15:39:51 CST(-0600)] <cindyli> since "timeupdate" event is fired every 250 miliseconds

[15:39:57 CST(-0600)] <Bosmon> In terms of how to test 102-168, your strategy should be similar

[15:39:59 CST(-0600)] <cindyli> which seems expensive,

[15:40:06 CST(-0600)] <Bosmon> That is, to generate a synthetic source of these custom video events

[15:40:36 CST(-0600)] <Bosmon> That part can be done just using jQuery.trigger, whereas the setInterval stuff will require a custom stub

[15:40:36 CST(-0600)] <colinclark> I probably won't help much if I wade into this conversation, but it's so interesting

[15:41:03 CST(-0600)] <cindyli> ah, jQuery.trigger

[15:41:07 CST(-0600)] <colinclark> I always wondered about Charly's strategy of binding VideoElement.timeupdate to an Infusion event...

[15:41:34 CST(-0600)] <cindyli> it's practical and reasonable tho

[15:41:36 CST(-0600)] <colinclark> Interestingly, I also had concerns about the mechanics of the timeupdate event in the Media Element spec as a whole

[15:41:43 CST(-0600)] <colinclark> It seems "upside down"

[15:41:56 CST(-0600)] <Bosmon> This is all interesting, since "in theory" designing for testability would in general lead to better designs in any case

[15:42:02 CST(-0600)] <colinclark> in that the key is that for many cases, such as captions, you actually know well ahead of time when things should happen

[15:42:02 CST(-0600)] <Bosmon> But there are always wrong turns to take

[15:42:21 CST(-0600)] <colinclark> Meaning, in the case of captions, you already know when a caption transition event occurs--either the start or end time of the caption

[15:42:38 CST(-0600)] <Bosmon> colinclark - but could you know reliably when that time actually IS?

[15:42:59 CST(-0600)] <colinclark> Well, I always imagined that the Media Element should have some way for you to register a callback for a given time

[15:43:09 CST(-0600)] <colinclark> And it would be responsible for reliably knowing when

[15:43:20 CST(-0600)] <Bosmon> But, I'm assuming, it doesn't...

[15:43:27 CST(-0600)] <colinclark> It does not, no

[15:43:37 CST(-0600)] <colinclark> But I wonder if the point is not to expose time update as an Infusion event

[15:43:42 CST(-0600)] <colinclark> but rather to expose something analogous

[15:43:46 CST(-0600)] <colinclark> to what I was hoping for

[15:43:58 CST(-0600)] <Bosmon> A general "notification by video time X" system?

[15:44:01 CST(-0600)] <Bosmon> Yes, that would seem useful

[15:44:02 CST(-0600)] <colinclark> yes

[15:44:13 CST(-0600)] <Bosmon> I notice this guy has similar problems

[15:44:13 CST(-0600)] <Bosmon> http://klasconia.wordpress.com/2010/10/19/html5-video-sequencing-the-timeupdate-even/

[15:44:29 CST(-0600)] <colinclark> I mean, I just don't think our Infusion event system was intended for this kind a use case

[15:44:39 CST(-0600)] <colinclark> where it's being fired at some indeterminately frequent interval

[15:44:49 CST(-0600)] <Bosmon> It's an interesting issue

[15:44:55 CST(-0600)] <Bosmon> And more properly, a job for the ChangeApplier

[15:45:00 CST(-0600)] <Bosmon> But I don't think it is up to it yet

[15:45:04 CST(-0600)] <colinclark> yes, exactly

[15:45:10 CST(-0600)] <Bosmon> It will get a bit closer when I do some ANTIFICATION

[15:45:13 CST(-0600)] <Bosmon> And I will keep this use case in mind

[15:45:17 CST(-0600)] <colinclark> I'm almost ready to advocate that if someone needs very fine-grained time events, they should get it by direct reference to the media element

[15:45:36 CST(-0600)] <colinclark> rather than assuming that we'll expose some changeapplier event that fires at a stable interview

[15:45:41 CST(-0600)] <Bosmon> Well, they should, apart from the risk that that poses for testability

[15:45:48 CST(-0600)] <colinclark> Right

[15:45:53 CST(-0600)] <Bosmon> So I think this poses a need for "something" synthetic that is not the media element itself

[15:45:55 CST(-0600)] <colinclark> that needs some mock or stub for testing

[15:45:57 CST(-0600)] <colinclark> yes

[15:46:00 CST(-0600)] <colinclark> exactly!

[15:46:02 CST(-0600)] <Bosmon> And if we make it, we may as well make it usable : P

[15:46:32 CST(-0600)] <colinclark> So the other worry I have with using setInterval instead of timeupdate is that I think we have no guarantee that it will fire stably

[15:46:50 CST(-0600)] <colinclark> This is generally my experience with Flocking, processing sound at something like 100ms increments

[15:47:05 CST(-0600)] <colinclark> JavaScript just isn't going to fire reliably on time

[15:47:18 CST(-0600)] <colinclark> whereas I expect that timeupdate has been optimized to fire reliably

[15:47:31 CST(-0600)] <Bosmon> Yes

[15:47:34 CST(-0600)] <colinclark> Even if that interval, if I remember correctly, is not actually specified in the MediaElement spec

[15:47:38 CST(-0600)] <Bosmon> All kinds of problems with setInterval

[15:47:54 CST(-0600)] <cindyli> what, you guys make me cry

[15:47:57 CST(-0600)] <colinclark> I know that, for example, Mozilla has been reducing the density of timeupdate events in various FF releases

[15:48:04 CST(-0600)] <colinclark> cindyli: I'm sorry!

[15:48:07 CST(-0600)] <Bosmon> Sorry, cindyli

[15:48:17 CST(-0600)] <colinclark> You remain completely awesome, cindyli

[15:48:17 CST(-0600)] <cindyli>

[15:48:27 CST(-0600)] <cindyli> not at this moment, i feel

[15:48:33 CST(-0600)] <Bosmon> Is it ok to pretend you were chopping some onions? : P

[15:48:39 CST(-0600)] <colinclark> lol

[15:48:40 CST(-0600)] <cindyli> haha

[15:48:47 CST(-0600)] <colinclark> We can all cry with cindyli

[15:49:02 CST(-0600)] <colinclark> This is such a fascinating topic

[15:49:07 CST(-0600)] <colinclark> so don't mind our meekness, cindyli

[15:49:10 CST(-0600)] <Bosmon> And an awful lot depends on the use case as well.... "what purpose are the events guaranteed to be good for"

[15:49:19 CST(-0600)] <colinclark> that should have been "geekiness"

[15:49:40 CST(-0600)] <colinclark> cindyli: Do you have a good feeling for when this event is actually used without our VideoPlayer?

[15:49:52 CST(-0600)] <colinclark> i.e. which components need it, and for what work?

[15:50:09 CST(-0600)] <cindyli> it's used to update the time progress

[15:50:11 CST(-0600)] <cindyli> and captions

[15:50:19 CST(-0600)] <Bosmon> ok

[15:50:23 CST(-0600)] <Bosmon> So it doesn't need to be "really good" then

[15:50:58 CST(-0600)] <colinclark> I gather that even a 250ms interval is something professional caption-y types have complained about

[15:51:09 CST(-0600)] <Bosmon> Yes, I would complain at that

[15:51:11 CST(-0600)] <colinclark> 1 second resolution is probably not ideal

[15:51:22 CST(-0600)] <michelled> I guess transcripts and audio descriptions will need it too

[15:51:27 CST(-0600)] <colinclark> Yes

[15:51:41 CST(-0600)] <Bosmon> When I made my caption set using "Universal Subtitles" I tried to be say in the 150ms ballpark or so

[15:51:42 CST(-0600)] <colinclark> My understanding is that timeupdate really isn't actually adequate for displaying captions

[15:51:49 CST(-0600)] <colinclark> hence the pending <track> element

[15:51:50 CST(-0600)] <michelled> audio description will probably want to be more fine tuned

[15:51:51 CST(-0600)] <colinclark> but we have to use what we've got

[15:51:59 CST(-0600)] <Bosmon> Yes

[15:52:01 CST(-0600)] <michelled> because you don't want them to play during the video audio

[15:52:07 CST(-0600)] <colinclark> So we should probably try to go as close to the metal as possible

[15:52:15 CST(-0600)] <colinclark> The metal being the MediaElement and its timeupdate event

[15:52:22 CST(-0600)] <Bosmon> And all of this points to the fact that we need a "stable, pluggable abstraction" that will allow any source of time updates to be swapped in

[15:52:38 CST(-0600)] <Bosmon> Whether it is a synthetic one for testing, timeupdate, or some as yet uninvented thing

[15:52:44 CST(-0600)] <colinclark> Bosmon: Can you elaborate on what you're thinking?

[15:53:01 CST(-0600)] <Bosmon> Well, it needs to be a kind of "event filter"

[15:53:04 CST(-0600)] <colinclark> I was just thinking a mock MediaElement might be the way to go--and not rebroadcasting time event as a changeapplier event

[15:53:22 CST(-0600)] <Bosmon> On the outside, are things that can register to be notified "ON OR AFTER" moving into a particular time segment

[15:53:25 CST(-0600)] <colinclark> at least until we can "invert" the event model for this

[15:53:28 CST(-0600)] <Bosmon> On the inside, is a source of time information

[15:53:34 CST(-0600)] <colinclark> yes, that sounds about right

[15:54:06 CST(-0600)] <Bosmon> I think, in theory, we don't actually want an "time event system" at all

[15:54:21 CST(-0600)] <Bosmon> Well, I guess we do, for showing "progress so far"

[15:54:32 CST(-0600)] <Bosmon> But really the job of the captions system should be able to be offloaded

[15:54:52 CST(-0600)] <Bosmon> The "thing" can receive a set of time intervals, together with a set of ids attached to them

[15:55:08 CST(-0600)] <Bosmon> And at any time there is a "change" of the most appropriate interval which is NOW, an event is fired, indicating what the new state is

[15:55:17 CST(-0600)] <Bosmon> Either a "transition to new id" or "transition to nothing"

[15:55:58 CST(-0600)] <Bosmon> And there's no reason why this couldn't be given an API compatible with ChangeApplier events, even if it doesn't use any of the machinery

[15:57:09 CST(-0600)] <Bosmon> I'm struggling to find on our ChangerApplier API page what this actually is

[15:57:37 CST(-0600)] <Bosmon> Ok, yes

[15:57:49 CST(-0600)] <colinclark> There are definitely cases where the timeupdate model is what a user would want

[15:57:50 CST(-0600)] <Bosmon> The event can just have the arguments (newId, oldId)

[15:58:01 CST(-0600)] <colinclark> but we certainly don't need it for captions, audio descriptions, or synched transcripts

[15:58:07 CST(-0600)] <colinclark> the inverted model would be great

[15:58:19 CST(-0600)] <colinclark> I guess the thing cindyli needs from us all...

[15:58:24 CST(-0600)] <colinclark> is what should we do next?

[15:58:29 CST(-0600)] <Bosmon> And the timeupdate can just have the arguments (newTime, oldTime)

[15:58:42 CST(-0600)] <Bosmon> This preserves a generally consistent semantic for people listening to events of either type

[15:59:14 CST(-0600)] <Bosmon> Ok, what I suggest is this - package together a "mini-component" which contains two standard fluid event firers

[15:59:24 CST(-0600)] <Bosmon> One of them "timeChange", the other of them "intervalChange"

[15:59:57 CST(-0600)] <colinclark> What will make them tick?

[16:00:01 CST(-0600)] <Bosmon> And then a means for it to accept i) a thing which on some schedule fires timeChange events, and ii) a list of intervals and ids, which it uses internally to fire the intervalChange event

[16:00:48 CST(-0600)] <colinclark> To satisfy the current API, cindyli, you could start by just implementing the first--the timeChange event

[16:00:51 CST(-0600)] <Bosmon> And so the thing in case i) can be a timeUpdate, something synthetic, or anything else - its only contract is that it "periodically fires timeChange events until it is destroyed"

[16:01:43 CST(-0600)] <colinclark> So, Bosmon...

[16:01:47 CST(-0600)] <Bosmon> I guess we can't even guarantee that the events will be fired in increasing order

[16:01:54 CST(-0600)] <Bosmon> Since the user may seek along the timeline however they like

[16:02:18 CST(-0600)] <Bosmon> As well as the thing "stalling" from time to time as a result of data running dry

[16:02:22 CST(-0600)] <colinclark> I guess in its simplest concrete implementation, this mini component would basically just connect up a MediaElement's timeupdate event to the .fire method of the timeChange event firer, right?

[16:02:29 CST(-0600)] <colinclark> Bosmon: Yes, that's correct

[16:02:39 CST(-0600)] <Bosmon> colinclark - that's right

[16:02:40 CST(-0600)] <colinclark> They could well scrub backwards or whatever

[16:02:55 CST(-0600)] <colinclark> cindyli: So I'd say that's your first step, which you can do tomorrow morning if you feel like it

[16:03:13 CST(-0600)] <colinclark> and then we can talk about where the "inverted" intervalChange event fits into our to do list

[16:03:23 CST(-0600)] <cindyli> ok

[16:03:37 CST(-0600)] <colinclark> I think we probably do want it sooner rather than later

[16:03:40 CST(-0600)] <Bosmon> cindyli - so the code in "captionner.js" which is currently in the prvate function "findCaptionForTime" belongs in the more mature version of this "minicomponent"

[16:03:49 CST(-0600)] <colinclark> it'll be an awfully fascinating implantation to write, cindyli

[16:03:51 CST(-0600)] <colinclark> which is lucky for you

[16:03:51 CST(-0600)] <Bosmon> The "inverted intervalChange" which colinclark is talking about

[16:04:16 CST(-0600)] <Bosmon> It will be a great opportunity to break out this implementation into a proper public algorithm too

[16:04:47 CST(-0600)] <colinclark> Bosmon: Can you point me to a line number?

[16:04:56 CST(-0600)] <colinclark> Because I'm exceedingly distracted and maybe a tiny bit lazy

[16:04:58 CST(-0600)] <colinclark>

[16:05:16 CST(-0600)] <colinclark> I'm so glad we're talking through this...

[16:05:16 CST(-0600)] <Bosmon> https://github.com/fluid-project/videoPlayer/blob/master/js/VideoPlayer_captionner.js#L21-38

[16:05:30 CST(-0600)] <colinclark> this whole event design has been swimming in my head periodically since I originally wrote the Video Player

[16:05:33 CST(-0600)] <colinclark> thanks, Bosmon

[16:05:57 CST(-0600)] <colinclark> oh good, Charly actually took my mess there and made it suck less

[16:06:07 CST(-0600)] <colinclark> and even wrote a comment about it not sucking

[16:06:48 CST(-0600)] <Bosmon> I'm not sure that this implementation will work correctly in the case of backscrubbing....

[16:07:01 CST(-0600)] <Bosmon> So it will be all to the good to get this on a footing where we can write test cases

[16:07:07 CST(-0600)] <colinclark> It looks like it won't, yes

[16:07:22 CST(-0600)] <colinclark> cindyli: Is this useful? Do you feel like you know what the next steps are and how to actually do them?

[16:07:43 CST(-0600)] <cindyli> it's certainly useful

[16:08:17 CST(-0600)] <cindyli> still have some questions for certain too

[16:08:27 CST(-0600)] <Bosmon> Ask away, if you can think of any of them right away....

[16:08:42 CST(-0600)] <cindyli> that's what i'm thinking

[16:08:49 CST(-0600)] <Bosmon>

[16:09:00 CST(-0600)] <colinclark> we'll be around tomorrow, too

[16:09:05 CST(-0600)] <colinclark> cindyli: for the record

[16:09:06 CST(-0600)] <colinclark> you rule

[16:09:11 CST(-0600)] <colinclark> this is going to be awesome

[16:09:20 CST(-0600)] <cindyli> what needs to be done when timeupdate event gets fired, update caption and time progress?

[16:09:58 CST(-0600)] <Bosmon> cindyli - the first thing that gets done is that you fire the "timeChange" event

[16:10:07 CST(-0600)] <Bosmon> The next thing is to decode the id of any new interval that is now valid

[16:10:17 CST(-0600)] <Bosmon> And then to fire an "intervalChange" event if it is different from the previous state

[16:10:36 CST(-0600)] <Bosmon> time progress will listen to the first event, update caption will listen to the second one

[16:10:36 CST(-0600)] <cindyli> ok

[16:10:59 CST(-0600)] <cindyli> ah

[16:11:13 CST(-0600)] <colinclark> and behind the scenes, you'll make it so the thing that the timeChange event is bound to is swappable

[16:11:24 CST(-0600)] <colinclark> meaning you can put in a synthetic "media element" for unit testing

[16:11:31 CST(-0600)] <colinclark> the "ticker"

[16:13:55 CST(-0600)] <cindyli> colinclark mentioned timeChange event connects up a MediaElement's timeupdate event to the .fire method of the firer

[16:14:05 CST(-0600)] <Bosmon> We might want a better impl in there relatively soon as well - this might suck up a lot of CPU on playing a long video with many captions

[16:14:17 CST(-0600)] <Bosmon> Since it is currently linear time in the number of captions for every timer tick

[16:14:28 CST(-0600)] <Bosmon> It is probably a saving grace that these are not currently very frequent

[16:14:52 CST(-0600)] <cindyli> is this mediaElement the one that we plan to integrate

[16:15:06 CST(-0600)] <colinclark> No, just the Video object

[16:15:09 CST(-0600)] <cindyli> or just a general term of <video>

[16:15:11 CST(-0600)] <cindyli> oh, i see

[16:15:11 CST(-0600)] <colinclark> yep, that

[16:15:30 CST(-0600)] <Bosmon> cindyli - ultimately, it doesn't matter too much - we plan this to be IoC configurable in any case

[16:15:33 CST(-0600)] <colinclark> I guess MediaElement.js will provide us with a JS API on top of a Flash movie that is identical

[16:15:42 CST(-0600)] <Bosmon> I imagine we will make a number of standard "timer wiring factories"

[16:16:01 CST(-0600)] <colinclark> So far, the ones I can imagine will all implement a "timeupdate" event

[16:16:05 CST(-0600)] <cindyli> sounds complicated

[16:16:10 CST(-0600)] <Bosmon> For example fluid.videoPlayer.timeUpdateAdapter

[16:16:17 CST(-0600)] <Bosmon> colinclark - has that name been standardised?

[16:16:21 CST(-0600)] <colinclark> It's in the spec, yes

[16:16:24 CST(-0600)] <Bosmon> Great

[16:16:28 CST(-0600)] <colinclark> Poor casing choice and all

[16:16:54 CST(-0600)] <colinclark> http://dev.w3.org/html5/spec/video.html#event-media-timeupdate

[16:17:16 CST(-0600)] <colinclark> The note is noteworthy

[16:17:17 CST(-0600)] <Bosmon> But as with everything else we design, we need to ensure that future kinds of media element can be wired up to our player without someone having to patch our source code

[16:17:20 CST(-0600)] <colinclark> "The current playback position changed as part of normal playback or in an especially interesting way, for example discontinuously. "

[16:18:26 CST(-0600)] <Bosmon> cindyli - it needn't be very complicated - there will just be a subcomponent configured attached to the "mini-component" which does the necessary wiring on startup

[16:18:34 CST(-0600)] <Bosmon> Very similar to our current style of "event binding subcomponents"

[16:18:48 CST(-0600)] <Bosmon> And given it is a component, it will have to have a name.....

[16:19:28 CST(-0600)] <cindyli> ok. will try

[16:20:03 CST(-0600)] <colinclark> So, you're saying that, in this concrete case, it will be a tiny little component with an init function that just does the work of binding the <video> tag's timeupdate event to our timeChange event, Bosmon?

[16:20:15 CST(-0600)] <Bosmon> colinclark - exactly

[16:20:48 CST(-0600)] <colinclark> Seems pretty straightforward. I can review your code for you if it helps, cindyli

[16:20:49 CST(-0600)] <Bosmon> And in the testing configuration, we will replace this with one that accepts a driver from the test case itself

[16:21:02 CST(-0600)] <colinclark> I'd love to pair program with you--but I have a 10 am meeting so I don't want to slow you down

[16:21:25 CST(-0600)] <cindyli> that's ok, colinclark, i have a better understanding now

[16:21:42 CST(-0600)] <colinclark> This stuff is just all so cool

[16:22:19 CST(-0600)] <colinclark> Bosmon: I was speculating to cindyli a bit earlier about what both setInterval and MediaElement.timeupdate do when the user switches to a different tab

[16:22:24 CST(-0600)] <cindyli> why do we wanna do a separate wiring on timeUpdate event rather than a direct use of it?

[16:22:39 CST(-0600)] <Bosmon> cindyli - only one "wiring"

[16:22:57 CST(-0600)] <Bosmon> The "adaptor thing" drives "timeChanged" from timeupdate

[16:23:04 CST(-0600)] <Bosmon> And everything else goes on from there

[16:23:16 CST(-0600)] <cindyli> right. why

[16:23:29 CST(-0600)] <cindyli> since our timeChanged === timeupdate

[16:23:31 CST(-0600)] <Bosmon> Noone wants to bind directly to timeupdate since it is a "native thing" which is exactly what we need to isolate

[16:23:38 CST(-0600)] <Bosmon> Well, it is only "===" in our minds, today : P

[16:23:59 CST(-0600)] <Bosmon> Every thing you fail to isolate, is something you need to think how to mock up in a test case

[16:24:00 CST(-0600)] <cindyli> ok, i see your point

[16:24:13 CST(-0600)] <Bosmon> And also something which may result in unforseen change in a future design

[16:24:39 CST(-0600)] <cindyli> understand

[16:24:42 CST(-0600)] <colinclark> Just hedging our bets

[16:24:50 CST(-0600)] <cindyli> cool. thanks guys

[16:25:33 CST(-0600)] <colinclark> thank you, cindyli

[16:25:40 CST(-0600)] <colinclark> made for a pretty fun collaborative design session

[16:25:47 CST(-0600)] <colinclark> I have been so stuck writing super boring RFPs

[16:25:47 CST(-0600)] <Bosmon> cindyli - as a general "code smell", always watch out for cases where you find yourself i) replacing a native implementation like setInterval and/or ii) creating a piece of public modifiable state like fluid.videoPlayer.media.intervalList

[16:25:47 CST(-0600)] <cindyli>

[16:25:52 CST(-0600)] <colinclark> getting to talk about code is awesome

[16:26:06 CST(-0600)] <colinclark> writing code is awesomer

[16:26:09 CST(-0600)] <Bosmon> Even in cases where you have properly namespaced it, it is generally a symptom of something which could be dealt with differently

[16:26:34 CST(-0600)] <colinclark> It's true. I remember a long time ago writing something quite similar to this, cindyli

[16:26:46 CST(-0600)] <cindyli> agree, but that the only way i could figure out to test setIntervals

[16:26:54 CST(-0600)] <colinclark> So the fact that we both wrote similar implementations is a sign that it's a larger problem to solve

[16:27:05 CST(-0600)] <cindyli> lol

[16:27:29 CST(-0600)] <colinclark> I think that code probably still exists in jQUnit somewhere, frighteningly

[16:27:46 CST(-0600)] <colinclark> I was excited to name it something like "subvertSetTimeout" or something to that effect

[16:27:56 CST(-0600)] <colinclark> it made setTimeout occur synchronously

[16:28:35 CST(-0600)] <Bosmon> I also remember "subvertAnimations" : P

[16:28:43 CST(-0600)] <colinclark> right, that was it

[16:28:47 CST(-0600)] <Bosmon> But sometimes it is too much to expect someone to have exposed a testing surface for EVERYTHING

[16:28:56 CST(-0600)] <Bosmon> But in cases where we are writing our own implementation, we can always do it

[16:29:21 CST(-0600)] <colinclark> yep, and interestingly I think subvertAnimations is now just never used because of this

[16:30:04 CST(-0600)] <cindyli> alrite, i'm getting off. i will go thru the rest conversation tomorrow. so great that irc talks are logged

[16:30:19 CST(-0600)] <Bosmon> Well, jquery animations are a pretty "grass roots" kind of thing.. and also they are not implementation-critical

[16:30:29 CST(-0600)] <Bosmon> So I think it was probably ok to subvert them

[16:30:37 CST(-0600)] <Bosmon> colinclark - is it no longer used?

[16:30:45 CST(-0600)] <Bosmon> Where was it used originally?

[16:30:50 CST(-0600)] <colinclark> Guess

[16:30:51 CST(-0600)] <colinclark>

[16:31:02 CST(-0600)] <Bosmon> Uploader?

[16:32:11 CST(-0600)] <colinclark> you've got it

[16:32:40 CST(-0600)] <Bosmon> But I assume that that call was only ever issued from test case.....

[16:32:43 CST(-0600)] <Bosmon> cases

[16:33:07 CST(-0600)] <colinclark> yep, that's what it was for

[16:33:12 CST(-0600)] <colinclark> it was in jQUnit

Browser not supported