20:57:48 RRSAgent has joined #mediacap 20:57:48 logging to http://www.w3.org/2014/03/27-mediacap-irc 20:57:50 RRSAgent, make logs public 20:57:52 Zakim, this will be MCAP 20:57:52 ok, trackbot; I see UW_MdCap()5:00PM scheduled to start in 3 minutes 20:57:53 Meeting: Media Capture Task Force Teleconference 20:57:53 Date: 27 March 2014 20:58:04 zakim, who's on the phone? 20:58:04 UW_MdCap()5:00PM has not yet started, burn 20:58:06 On IRC I see RRSAgent, adambe, fluffy, dom, Zakim, jesup, fjh, burn, JimBarnett, stefanh, slightlyoff, Josh_Soref, timeless_, derf, trackbot 20:58:24 jib_ has joined #mediacap 20:59:33 Zakim, code? 20:59:33 the conference code is 6227 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), dom 20:59:35 gmandyam has joined #mediacap 20:59:39 mt has joined #mediacap 20:59:51 lgombos has joined #mediacap 21:00:32 zakim, who's on the phone? 21:00:32 UW_MdCap()5:00PM has not yet started, burn 21:00:34 On IRC I see lgombos, mt, gmandyam, jib_, RRSAgent, adambe, fluffy, dom, Zakim, jesup, fjh, burn, JimBarnett, stefanh, slightlyoff, Josh_Soref, timeless_, derf, trackbot 21:00:38 Zakim, this is mdcap 21:00:38 ok, dom; that matches UW_MdCap()5:00PM 21:00:41 adam has joined #mediacap 21:00:42 Zakim, who's on the call? 21:00:42 On the phone I see Dan_Burnett, +1.403.244.aaaa, jesup, +46.1.07.14.aabb, +1.214.343.aacc, stefanh, Jim_Barnett, +91.22.39.14.aadd, [Microsoft], +1.267.934.aaee, gmandyam, ??P17 21:00:52 Zakim, ??P17 is me 21:00:53 +dom; got it 21:00:55 zakim, I am Dan_Burnett 21:00:55 ok, burn, I now associate you with Dan_Burnett 21:01:09 zakim, I am aaee 21:01:10 +jib_; got it 21:01:11 Zakim, aaaa is me 21:01:11 +fluffy; got it 21:01:13 zakim, I am aacc 21:01:13 +adam; got it 21:01:27 +[Mozilla] 21:01:37 +??P19 21:01:55 [Mozilla] is mt & ekr 21:02:16 Zakim, [Mozilla] is mt and ekr 21:02:16 I don't understand '[Mozilla] is mt and ekr', adam 21:02:22 Shijun_Sun has joined #mediacap 21:02:24 juberti has joined #mediacap 21:02:26 +[IPcaller] 21:02:30 zakim, ipcaller is me 21:02:30 +fjh; got it 21:02:34 Zakim, [Mozilla] is mt 21:02:34 +mt; got it 21:03:31 + +47.41.44.aaff 21:03:41 zakim, [Mozilla] includes ekr 21:03:41 I don't understand '[Mozilla] includes ekr', burn 21:04:33 proposed agenda http://lists.w3.org/Archives/Public/public-media-capture/2014Mar/0123.html 21:04:42 +Stephane_Cazeaux 21:04:53 q+ to remind of call recording 21:05:07 stephane has joined #mediacap 21:05:30 scribenick: mt 21:05:30 +??P24 21:05:46 Agenda: http://lists.w3.org/Archives/Public/public-media-capture/2014Mar/0123.html 21:05:49 minutes http://lists.w3.org/Archives/Public/public-media-capture/2013Nov/0139.html 21:05:51 Topic: Minutes approval 21:06:20 stefanh: the minutes for approval 21:06:40 fluffy: these are the same minutes I had problems with? 21:06:48 fluffy: in which case I object 21:06:59 juberti: that might have been the previous meeting 21:07:04 ekr has joined #mediacap 21:07:25 stefanh: your objection was to webrtc minutes 21:07:30 fluffy: ah, no 21:07:37 ekr: proposes to postpone 21:08:00 hta has joined #mediacap 21:08:06 topic: agenda 21:08:25 my slides: http://lists.w3.org/Archives/Public/public-media-capture/2014Mar/att-0158/constraints20140327.pdf 21:08:48 Topic: Existing design of constraints 21:09:07 zakim, who's here? 21:09:07 On the phone I see Dan_Burnett, fluffy, jesup, +46.1.07.14.aabb, adam, stefanh, Jim_Barnett, +91.22.39.14.aadd, [Microsoft], jib_, gmandyam, dom, mt, ??P19, fjh, +47.41.44.aaff, 21:09:09 burn: will outline changes in the last year and the syntax that results 21:09:11 ... Stephane_Cazeaux, ??P24 21:09:11 On IRC I see hta, ekr, stephane, juberti, Shijun_Sun, adam, mt, gmandyam, jib_, RRSAgent, adambe, fluffy, dom, Zakim, jesup, fjh, burn, JimBarnett, stefanh, slightlyoff, 21:09:11 ... Josh_Soref, timeless_, derf, trackbot 21:09:19 zakim, aaff is me 21:09:19 +hta; got it 21:10:09 burn: one of the biggest changes is that the optional elements can now include multiple attribute and value pairs (as opposed to just one) 21:10:15 +??P25 21:10:22 burn: this is the same value for "optional" as for "mandatory" 21:10:29 -adam 21:10:41 Zakim, ??P25 is me 21:10:41 +adam; got it 21:11:19 burn: there is a separate interface: Constrainable 21:12:54 The problem is that the minutes are always bad 21:13:37 burn: ConstraintSet is the core property, in which you can have specific values, min/max, or enumerated 21:13:39 Zakim, Microsoft is me 21:13:40 +Shijun_Sun; got it 21:14:15 burn: the order of optional properties is significant 21:14:56 burn: applyConstraints and gUM are the two places that constraints (and Constrainable) is used 21:15:03 @ Stefan - you are right it was the WebRTC minutes I had a problem with. I have no idea if the minutes from last Media TF are right or wrong but I have no objections to them be approved if you feel like asking again at end of call 21:16:57 burn: applyConstraints is different from what is passed to gUM because applyConstraints is applied to a track - where you already know if it is audio or video 21:17:07 -??P19 21:17:27 burn: all mandatory constraints MUST be satisfied; optional constraints are attempted, starting from the first 21:17:57 burn: this is also true when changing constraints 21:18:35 ekr: this is expanded as of previously, because you can specify sets of properties, instead of single properties 21:18:48 burn: correct 21:19:12 burn: an entirely constraint set must be satisfied together 21:20:09 burn: capabilities return multiple values (ranges or sets) 21:20:22 burn: settings (as applied) return a single value 21:20:30 lgombos has joined #mediacap 21:21:53 burn: typo on slides s/1280/1080/ 21:22:41 juberti: if you can't get 1080 exactly, but if you can get close, then you would fall back to 4:3. 21:22:46 burn: correct 21:22:46 q? 21:23:13 juberti: would you get all values that a camera can do, or would you get a min-max range? 21:23:24 burn: min/max 21:23:37 juberti: why not specifics so that the application can choose directly? 21:23:51 it could be either - it depends on how the property is defined 21:24:24 burn: the complexity of returning multiple sets of values primarily 21:24:34 burn: combinatorial explosion 21:24:44 juberti: native applications manage 21:24:56 juberti: just curious about the rationale 21:25:30 fluffy: one of the issues is that modern cameras have near infinite combinations 21:25:55 juberti: they have to be finite; the APIs provide enumeration capabilities 21:26:17 burn: fingerprinting concerns caused us to avoid providing specifics in the past 21:26:51 burn: we now have a process by which we can determine when it's safe to provide more surface area 21:26:54 q? 21:26:59 q+ 21:27:08 q- 21:27:26 juberti: how are unknown mandatory constraints handled? please summarize 21:27:34 q+ 21:27:36 ack juberti 21:27:45 unknown mandatory cnstraints must fail (per current spec) 21:28:01 q? 21:28:03 burn: a mandatory property must be satisfied, else fail 21:28:09 q+ 21:28:28 burn: unclear on applyConstraints 21:28:53 ekr: this was my understanding and this is very important 21:29:02 ekr: if we don't agree about this, we should stop here 21:29:02 q+ 21:29:09 q ack 21:29:11 ack 21:29:18 q- ekr 21:29:22 ok, I have forgotten how to do that 21:29:23 "unknown property names will result in a ConstraintSet that can not be satisfied" 21:29:36 that seems pretty clear 21:29:51 jib_: these are not dictionaries, right? 21:29:57 JimBarnett: no, they are not 21:30:11 q- 21:30:17 jib_: where are the rules that define what is permitted and how to validate the values? 21:30:26 q? 21:30:30 I thought there was controversy on this point. Happy to hear that that is not the case 21:30:33 q- 21:30:54 hta: the only reason we cannot use dictionary is that we can't check for unknown members on the object 21:31:00 q+ 21:31:11 hta: these are almost dictionaries 21:31:23 jib_: are these objects passed by value or reference? 21:31:30 hta: by-value 21:31:40 jib_: object is passed by reference 21:31:52 ekr: why is this an important question? 21:32:19 ekr: is there a way to set a constraint and have the process fail if it is not met 21:32:25 fluffy: I think we already have agreement on that 21:32:40 juberti: wanted to clear up the point 21:32:45 My slides: http://lists.w3.org/Archives/Public/public-media-capture/2014Mar/0142.html 21:32:51 topic: Jan-Ivar's presentation 21:33:26 http://lists.w3.org/Archives/Public/public-media-capture/2014Mar/att-0142/Constraints2014.pdf 21:35:07 jib: dictionaries don't allow for unknown or repeated members 21:36:02 jib: dictionaries are passed by value; IDL bindings do type checking 21:36:08 jib: objects are passed by reference in JS 21:36:51 NO! order doesn't matter within a constraint set 21:37:03 It's only when you list constraint sets that order comes in 21:37:06 q+ 21:37:11 q+ 21:37:19 q- jib_ 21:37:23 JimBarnett: are you going to make this point. 21:37:36 ack JimBarnett 21:37:37 q- 21:38:01 JImBarnett: order only matters if you have multiple constraint sets 21:39:06 JimBarnett: the entire set must be satisfied as a unit, if not you move on 21:39:44 +q 21:39:50 jib_: prior to the latest change, there is ordering between constraints 21:40:15 q+ 21:40:30 burn: this was restricting us to a single property name-value, but it was always the case that those were independent and the optional array that provided the ordering 21:41:20 jib_: what is on slide 2 is not possible today 21:41:36 JimBarnett: then you would have 4 constraint sets in some order 21:41:44 burn: or more if you split min and max 21:42:38 jib_: this structure doesn't imply any order and allows the UA to choose 21:42:43 q? 21:42:49 q+ 21:43:18 hta: the browser is allowed to do what it likes on any of these values 21:43:37 jib_: we might encourage the browser to pick the source that matches the most constraints 21:43:48 hta: so these are hints 21:44:02 q+ 21:44:07 ack adambe 21:44:37 ack fluffy 21:44:37 adambe: agrees with Jan-Ivar that this is not possible today 21:45:07 cullen… jan-ivar does have a syntax for that 21:45:15 adam, the behavior he describes is absolutely possible today, just with a different syntax than he shows 21:45:21 fluffy: the important point in this discussion is that being able to specify in the optional constraints which is most important to the app is the feature that is most important 21:45:33 q? 21:45:38 q- 21:45:46 fluffy: allowing the browser some latitude might be important, but there needs to be a way for the app to make some calls 21:45:50 q- 21:45:58 burn, it seems to me that you can't have the exact equivalent since you *have* to provide an order in your optional constraint sets 21:45:58 burn: back in my day... 21:45:58 burn: how? not by putting constraints in different elements or in the same element 21:46:39 burn: we had some browser freedom, but application developers wanted more control (something about mistrusting browsers) 21:46:51 burn: this is possible with the existing syntax 21:47:19 jib_: disagree. today you have to say that X is strictly more important than Y 21:47:25 q? 21:47:37 ack Dan 21:49:20 q+ 21:49:33 I would like to note that if the authors of the specs have to debate what is or is not even possible around fairly simple cases, we have developed an unusable spec. Developers will need a application just to build their constraint sets and be unable to know why they work or don't.... 21:49:53 q+ 21:50:57 q- 21:51:02 q- 21:51:04 jib_: describes prefer and ideal extensions 21:53:28 q+ 21:53:48 q+ 21:53:48 ack Dan 21:54:13 burn: pass by value/reference is an irrelevant distinction; the current syntax is intended to work the same way 21:54:27 ok, that was my question. 21:54:27 q- 21:54:49 lgombos_ has joined #mediacap 21:55:12 q+ 21:55:20 ack me 21:55:24 (I think the pass by value vs by ref is just another illustration of relying on WebIDL or our own micro-structure, not a specific argument) 21:55:38 jib_: objects are passed by reference; dictionaries are easier 21:55:39 q? 21:55:40 ack JimBarnett 21:55:46 Zakim, who's noisy? 21:55:59 dom, listening for 11 seconds I heard sound from the following: Dan_Burnett (21%), Jim_Barnett (26%), ??P24 (31%) 21:56:34 JimBarnett: if the important thing is to get WebIDL, we could send a list of dictionaries and use the require keyword in addition 21:56:39 q+ 21:57:58 burn/JimBarnett: back and forth on some other proposal 21:58:00 [I'm not sure it's productive to build on the fly a WebIDL-compatible version of the current design of contraints] 21:58:22 jib_: Jim's proposal is to take Jan-Ivar's proposal and add it to an ordered list 21:58:37 jib_: that's more complex, overkill 22:00:00 q+ 22:00:22 JimBarnett: wants expressiveness, complexity is justified based on that 22:00:25 ack flu 22:00:28 jib_: where's the use case? 22:00:53 fluffy: difference is in the semantics that can be expressed, then syntax (and syntax is not important) 22:01:27 fluffy: these are largely converged, aside from having the same constraint multiple times (can't have separate optional and mandatory) 22:01:39 fluffy: sourceId is one place we might need multiples 22:02:27 fluffy: Jan-Ivar, would you be willing to consider things that cover these 22:02:34 jib_: concerned about it being webIDL 22:02:36 q? 22:02:40 q+ 22:02:44 fluffy: that's easy to fix with a new syntax 22:03:04 jib_: for sourceId, you could provide a list/set of source IDs 22:03:29 q? 22:03:34 dictionary MediaTrackConstraints : Constraints { … ConstrainDOMString sourceId; } with ConstrainDOMString defined as either a string or an array of strings 22:03:40 ack jesup 22:03:46 q+ 22:03:47 Zakim, who's noisy? 22:03:53 jesup: we have created a very complex language for specifying stuff, not quite Turing-complete 22:04:06 dom, listening for 16 seconds I heard sound from the following: +91.22.39.14.aadd (6%) 22:04:36 jesup: expressivity might be useful for some, in which case, we've not done a good job of capturing requirements, because we can't evaluate proposals againstrequirements 22:04:49 q+ 22:05:01 +1 to all of what jesup says 22:05:10 jesup: the danger of defining the ur-solution is that it makes it harder to use 22:05:32 jesup: it's not a great thing for the web if users need a helper app just to construct constraints 22:05:41 q? 22:05:45 -1 to all of what jesup says 22:06:14 ack hta 22:06:15 hta: I don't see these as especially complex; each proposal is a small purpose built language 22:06:40 q+ 22:06:41 agree with hta, this is not at all complex compared to what developers have to deal with when listing and specifying all device settings in detail in other languages 22:06:43 hta: we have a proposal for a reduction in functionality, on a basis that is not especially compelling 22:07:34 hta: what can we do that does the least amount of damage to what we have already discussed 22:07:44 +1 to hta 22:07:47 hta: Jan-Ivar's proposal is a reduction in espressiveness 22:08:12 fluffy: disagree with jesup and (dom?) 22:08:22 fluffy: these two things are almost the same 22:08:29 q? 22:08:38 q+ 22:08:41 ack fluffy 22:08:42 fluffy: argument from precedent 22:08:43 ack ekr 22:09:14 ekr: if/else if/else is useful, not sure if Jan-Ivar's proposal can address that 22:09:16 ack jib 22:09:22 q+ 22:09:56 jib_: require addresses the mandatory problem, which is my main WebIDL beef 22:10:26 jib_: tried to do both things, reducing expressiveness and fixing webIDL 22:10:51 jib_: might look at the optional sequencing problem 22:11:32 fluffy: with the interaction with user prompts, not sure that we can avoid optional 22:11:57 (minute taker missed something here) 22:11:57 q? 22:11:59 q+ 22:12:35 juberti: backwards compatibility story: both proposals require churn in implementations 22:12:54 juberti: Jan-Ivar's proposal is more churn 22:12:55 q+ 22:13:14 q? 22:13:18 [I'm not sure to understand why this causes more churn in implementation] 22:13:19 q- 22:13:37 ack jesup 22:13:45 jesup: not saying either proposal is perfect, but there are requirements here that are not well captured and that makes it hard to evaluate 22:14:04 jesup: we should have discussed these requirements 22:14:26 jesup: I don't mind it being a language, but worry about complexity 22:14:51 jesup: the question is: how many people are using syntax that would be affected by either proposal 22:15:33 burn: I think that the requirements are out there and have been discussed for a while already 22:16:16 [back in November, we said we should go back to listing requirements for constraints; this hasn't happened, and this seems to confirm this hadn't been done before] 22:16:59 burn: these capabilities are not just for local use, they might be for RTCPeerConnection; where changing network conditions might require the browser to act without application input 22:17:23 q+ 22:17:36 burn: effective constraints are dynamic, within the constraints specified by a developer 22:17:52 Zakim, close the queue 22:17:52 ok, dom, the speaker queue is closed 22:18:33 burn: Congestion handling should be automatic, and not necessarily change the GUM resolution. That's a bad way to respond to congestion; changing scaling in PeerConnection is how to do that 22:18:54 -fjh 22:19:33 I suspect more developers will tend to overspecify when they try to use it and accidentally mess over users with configs they didn't expect 22:19:39 [another way to put it: reduced expressiveness is not an issue; sufficient expressiveness is what we should care about] 22:19:56 reduce expressiveness is not sufficient 22:20:04 jesup, changing scaling in PeerConnection will have an effect downstream, and that's exactly what I'm talking about 22:20:11 The current spec has the expressiveness we need 22:20:35 JimBarnett, I think the point is that the requirements of what is we need haven't laid down explicitly 22:20:42 So far, I haven't seen anyone articulate a real-world use case requiring all the expressiveness possible here. 22:20:59 Right now, people are using constraints to pick cameras, and choose HD vs VGA. 22:21:12 The one Dan gave has been there from the beginning 22:22:20 That could be done with a less expressive proposal. ideal=1080p, min=480p 22:22:22 fluffy: this has been expressive in this way since 2012-08 22:22:31 +1 to Cullen 22:22:35 q? 22:22:44 queue= 22:22:46 a different syntax with the same expressiveness is worth investigating 22:22:50 q- Dan 22:22:52 q- jib 22:22:54 But I don't want to lose expressiveness 22:22:55 q- fluffy 22:23:08 Zakim, reopen the queue 22:23:08 ok, dom, the speaker queue is open 22:23:14 I don't mind losing expressiveness and complexity that apps don't really need. 22:23:25 stefanh: we've talked about this, some people are concerned about complication, more people want expressiveness 22:23:27 Will we be taking a vote on the proposal? 22:23:37 especially if we can enumerate caps directly.. 22:23:41 stefanh: we don't have any consensus for reducing expressiveness 22:23:47 If I'm wrong about the requirements, great. Let's use that to evaluate them. But complexity is an issue as justin says 22:24:06 stefanh: would a more webIDL compatible API be worth pursuing? 22:24:15 JimBarnett: that would be good 22:24:57 burn: I would be fine with that, expressivity >> syntax 22:25:13 I would be ok with reducing expressiveness (barring a good argument that it has to be maintained for important reasons), or to modify jib's proposal to add it 22:26:00 likewise. the lack of conforming implementations at this point indicates that we won't have the desired expressiveness any time soon, even with the current proposal. 22:26:02 I would prefer to simplify, but am ok if we have strong reasons for needing complexity 22:26:30 stefanh: will ask jib_, JimBarnett, burn to work something out 22:26:39 Agree with jesup's previous comment on reducing expressiveness, or modifying jib's proposal to add it 22:26:40 I'd like to see a definition of *what* expressiveness is needed, and roughly why 22:27:24 We have a Use Cases/Requirements doc - we should be matching up requirements for expresiveness with that doc's use cases 22:27:42 expressiveness isn't free; it comes with a cost in complexity and implementation, which should be justified and balanced by the use cases they enable 22:28:09 dom, so should dramatically changing something that has largely been in the spec for a *very* long tim 22:28:48 are we going to discuss Constrainable as well? 22:28:48 My guess is that there are no use cases in the Use Case/Requirements doc that require expressiveness 22:29:03 fluffy: we want to be done, we need to ensure we don't lose anything 22:29:14 jesup: this is the first time it's really been implemented 22:29:45 stefanh: we'll give this group a few weeks to come up with something 22:30:03 fluffy: if we are going to change what semantics can be expressed, I'm not interested 22:30:12 fluffy: changing the syntax should be easy 22:31:24 dom: can we get use cases that require this broader expressiveness, even if we don't start from the position that we are changing expressiveness 22:31:38 q+ 22:32:01 burn: this is annoying, it will take ages to sort this out 22:32:08 q+ 22:33:01 dom: coming up with one use case would be simple 22:33:12 juberti: expressiveness isn't holding applications back 22:33:20 juberti: or lack thereof 22:33:40 fluffy: we don't have *any* use cases 22:33:51 fluffy: driving from use cases is too slow 22:33:52 [hmm... I think it might be slow *because* we don't have use cases and requirements] 22:34:37 fluffy: fixing the syntax should be quick 22:35:05 Just because we have not been actively revising https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html does not mean that the doc does not exist. It can be revised. 22:35:11 see slide 10 22:36:12 fluffy's comment about use cases was that none of our features have a use case and requirements document. He then made clear that the use cases for the current level of expressivity *have* been sent to the mailing list multiple times over the years. 22:36:18 hta: proposes that we fix the current proposal, then talk about reducing expressiveness 22:36:19 +1 22:36:47 But with Capabilities, we now have some alternate ways of dealing with this 22:37:15 I think it would be nice if we could let JS control this stuff instead of the constraints mini-language 22:38:41 (since the queue discipline is gone, I'm assuming that we're done with minutes too) 22:38:52 Justin, I suspect you would never get agreement with jib on direct control of device characteristics, esp. for devices shared across tabs, apps, etc. 22:39:18 -hta 22:39:20 -gmandyam 22:39:21 -dom 22:39:22 -adam 22:39:22 - +46.1.07.14.aabb 22:39:23 -jib_ 22:39:25 -mt 22:39:25 -Dan_Burnett 22:39:26 -fluffy 22:39:26 -??P24 22:39:27 -Jim_Barnett 22:39:27 -Stephane_Cazeaux 22:39:29 -jesup 22:39:29 Zakim, list attendees 22:39:29 As of this point the attendees have been Dan_Burnett, +1.403.244.aaaa, jesup, +46.1.07.14.aabb, +1.214.343.aacc, stefanh, Jim_Barnett, +91.22.39.14.aadd, +1.267.934.aaee, gmandyam, 22:39:33 ... dom, jib_, fluffy, adam, fjh, mt, +47.41.44.aaff, Stephane_Cazeaux, hta, Shijun_Sun 22:39:33 -Shijun_Sun 22:39:33 -stefanh 22:39:38 RRSAgent, draft minutes 22:39:38 I have made the request to generate http://www.w3.org/2014/03/27-mediacap-minutes.html dom 22:40:22 burn: I'm note sure you're right. Static languages to try to define these sorts of things always fail in expressiveness compared to code, if expressiveness is important 22:40:31 s/note/not/ 22:44:32 disconnecting the lone participant, +91.22.39.14.aadd, in UW_MdCap()5:00PM 22:44:34 UW_MdCap()5:00PM has ended 22:44:34 Attendees were Dan_Burnett, +1.403.244.aaaa, jesup, +46.1.07.14.aabb, +1.214.343.aacc, stefanh, Jim_Barnett, +91.22.39.14.aadd, +1.267.934.aaee, gmandyam, dom, jib_, fluffy, adam, 22:44:34 ... fjh, mt, +47.41.44.aaff, Stephane_Cazeaux, hta, Shijun_Sun 22:45:33 Shijun_Sun has left #mediacap 23:06:01 lgombos_ has joined #mediacap 23:35:17 jib has joined #mediacap 23:43:42 jib has joined #mediacap 23:43:42 lgombos_ has joined #mediacap 23:43:42 hta has joined #mediacap 23:43:42 adam has joined #mediacap 23:43:42 jesup has joined #mediacap 23:43:42 fjh has joined #mediacap 23:43:42 JimBarnett has joined #mediacap 23:43:42 slightlyoff has joined #mediacap 23:43:42 Josh_Soref has joined #mediacap 23:43:42 timeless_ has joined #mediacap 23:43:42 derf has joined #mediacap 23:59:19 ekr has joined #mediacap