IRC log of mediacap on 2014-08-05
Timestamps are in UTC.
- 14:56:49 [RRSAgent]
- RRSAgent has joined #mediacap
- 14:56:49 [RRSAgent]
- logging to http://www.w3.org/2014/08/05-mediacap-irc
- 14:57:04 [Zakim]
- Zakim has joined #mediacap
- 14:57:50 [burn]
- zakim, this is mcap
- 14:57:50 [Zakim]
- ok, burn; that matches UW_MdCap()11:00AM
- 14:58:11 [burn]
- zakim, who's here?
- 14:58:11 [Zakim]
- On the phone I see Dan_Burnett, ??P12
- 14:58:13 [Zakim]
- On IRC I see RRSAgent, jib, stefanh, burn, adam, richt, derf, Josh_Soref___, anssik_, timeless, slightlyoff, trackbot
- 14:58:19 [burn]
- zakim, this is Dan_Burnett
- 14:58:19 [Zakim]
- sorry, burn, I do not see a conference named 'Dan_Burnett' in progress or scheduled at this time
- 14:58:27 [adam]
- Zakim, I am ??P12
- 14:58:28 [Zakim]
- +stefanh
- 14:58:28 [Zakim]
- +adam; got it
- 14:58:33 [burn]
- zakim, I am Dan_Burnett
- 14:58:33 [Zakim]
- ok, burn, I now associate you with Dan_Burnett
- 14:59:32 [Jim_Barnett]
- Jim_Barnett has joined #mediacap
- 14:59:33 [Zakim]
- + +1.425.610.aaaa
- 14:59:49 [stefanh]
- details and proposed agenda for the call: http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/0004.html
- 14:59:57 [Zakim]
- + +1.408.421.aabb
- 14:59:59 [hta]
- hta has joined #mediacap
- 15:00:17 [fluffy]
- fluffy has joined #mediacap
- 15:00:22 [Zakim]
- + +1.267.934.aacc
- 15:00:29 [mt_]
- mt_ has joined #mediacap
- 15:00:43 [jib]
- zakim, I am aacc
- 15:00:43 [Zakim]
- +jib; got it
- 15:00:57 [Zakim]
- + +91.22.39.14.aadd
- 15:01:04 [gmandyam]
- gmandyam has joined #mediacap
- 15:01:05 [Zakim]
- +gmandyam
- 15:01:10 [Zakim]
- +[Mozilla]
- 15:01:47 [fluffy]
- zakim, who is here?
- 15:01:47 [Zakim]
- On the phone I see Dan_Burnett, adam, stefanh, +1.425.610.aaaa, +1.408.421.aabb, jib, +91.22.39.14.aadd, gmandyam, [Mozilla]
- 15:01:49 [Zakim]
- On IRC I see gmandyam, mt_, fluffy, hta, Jim_Barnett, Zakim, RRSAgent, jib, stefanh, burn, adam, richt, derf, Josh_Soref___, anssik_, timeless, slightlyoff, trackbot
- 15:02:09 [ekr]
- ekr has joined #mediacap
- 15:02:18 [Zakim]
- +[Microsoft]
- 15:02:33 [fluffy]
- zakim, aabb is fluffy
- 15:02:33 [Zakim]
- +fluffy; got it
- 15:03:19 [stefanh]
- details and agenda: http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/0004.html
- 15:03:29 [Shijun_Sun]
- Shijun_Sun has joined #mediacap
- 15:04:01 [Peter]
- Peter has joined #mediacap
- 15:04:15 [Zakim]
- -[Mozilla]
- 15:04:29 [Zakim]
- +Jim_Barnett
- 15:04:33 [Zakim]
- +[Mozilla]
- 15:05:08 [Zakim]
- + +47.41.44.aaee
- 15:05:20 [hta]
- zakim, aaaee is me
- 15:05:20 [Zakim]
- sorry, hta, I do not recognize a party named 'aaaee'
- 15:05:25 [hta]
- zakim, aaee is me
- 15:05:25 [Zakim]
- +hta; got it
- 15:05:33 [burn]
- scribenick burn
- 15:06:07 [stefanh]
- draft noted June 25: http://lists.w3.org/Archives/Public/public-media-capture/2014Jun/0144.html
- 15:06:11 [burn]
- stefan: first need to approve minutes from last call
- 15:06:14 [ekr]
- I have not reviewed these minutes
- 15:06:22 [burn]
- ... any problems with these minutes?
- 15:06:24 [ekr]
- I will do so now, please do not approve until end of call
- 15:06:42 [burn]
- ... will return to minutes approval at end of call
- 15:07:00 [burn]
- ... next is ideal algorithm, Peter will present
- 15:07:08 [stefanh]
- Peter's slides: http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/att-0019/Finding_an_-Ideal-_Algorithm__4_.pdf
- 15:07:19 [burn]
- Peter: mailed latest pdf this morning
- 15:07:42 [burn]
- ... 2 alternatives: min distance and advanced expansion
- 15:08:13 [burn]
- ... starting with min distance
- 15:08:29 [Jim_Barnett]
- How does this work with applyConstraints?
- 15:08:31 [ekr]
- q+
- 15:09:00 [burn]
- ... key is to calculate distance from all constraints for each possible device mode and choose the smallest
- 15:09:25 [hta]
- jim: I think it would work identically, except that only modes available for the selected device would be selected. Put yourself on the speaker queue if you wish to address this question in the chat.
- 15:10:00 [burn]
- ... note that there are different types of distances based on which constraint. for example, sourceId is weighted to require more exact matches
- 15:10:25 [burn]
- ekr: how does this work with cameras that pick a resolution and rescale?
- 15:11:03 [gmandyam]
- q+
- 15:11:11 [hta]
- q+
- 15:11:16 [burn]
- ... very difficult for me to enumerate all possibilities
- 15:11:47 [burn]
- justin: if there are no specific modes any choice is arbitary. idea is to do something comparable when you can't enumerate.
- 15:11:58 [burn]
- ekr: this is linear programming problem
- 15:12:07 [burn]
- cullen: no, just pick something reasonable/close here
- 15:12:25 [stefanh]
- zakim ack ekr
- 15:12:44 [burn]
- (can't catch all the discussion here)
- 15:13:27 [burn]
- ekr: I want someone to write me the code that does this in O(nsquared)
- 15:14:09 [mt_]
- zakim, who is noisy?
- 15:14:11 [ekr]
- Sorry, that's *not* n^2
- 15:14:20 [Zakim]
- mt_, listening for 10 seconds I heard sound from the following: 12 (15%), +1.425.610.aaaa (10%), fluffy (49%)
- 15:14:21 [ekr]
- Obviously n^2 is trivial
- 15:14:30 [hta]
- zakim, mute aaaa
- 15:14:30 [Zakim]
- +1.425.610.aaaa should now be muted
- 15:14:40 [burn]
- cullen: not linear programming. yes, combinations of frame rate and resolution will require more checking
- 15:14:59 [juberti]
- juberti has joined #mediacap
- 15:15:12 [burn]
- ekr: let's say camera has different resolutions, each of which comes with a different bitrate.
- 15:15:45 [burn]
- ... but you are given a table and not a function
- 15:15:48 [juberti]
- Zakim, who's noisy?
- 15:15:58 [Zakim]
- juberti, listening for 10 seconds I heard sound from the following: +91.22.39.14.aadd (4%), fluffy (96%), Jim_Barnett (4%)
- 15:16:05 [mt_]
- it could be a table or a maximum pixel rate
- 15:16:12 [burn]
- cullen: with table-based approach, can step through optimal value for each table entry
- 15:16:48 [burn]
- jib: in FF implementation some drivers enumerate all modes and some don't give you any. You have to guess when not given the info.
- 15:17:10 [burn]
- ekr: so you have to enumerate as a table?
- 15:17:45 [burn]
- cullen: typically told resolution x can be done up to this framerate, y up to this framerate, etc.
- 15:18:12 [burn]
- ... so in theory this is infinite, but in practice you don't have to do that.
- 15:18:40 [burn]
- ... often this is a function and not a table.
- 15:18:43 [juberti]
- q+
- 15:19:09 [burn]
- jib: doesnt' have to be perfect
- 15:19:19 [burn]
- ekr: no, you told me i had to do this algorithm.
- 15:19:36 [burn]
- cullen: in most cases can describe a closed-form solution
- 15:20:14 [burn]
- ekr: i complained about needing a complete constraint solver 2 years ago
- 15:20:25 [burn]
- jib: a third option is to just make them hints
- 15:21:06 [burn]
- stefan: some implementers are in the team that came up with this. any comments from them?
- 15:21:13 [fluffy]
- q?
- 15:21:16 [ekr]
- q-
- 15:21:34 [fluffy]
- I apoligize - I did not realize there were people on the Q
- 15:21:37 [burn]
- giri: was Euclidean distance rejected?
- 15:22:52 [mt_]
- for the record, having seen Jan-Ivar's code, ekr's concern is pretty valid.
- 15:22:57 [mt_]
- the mac camera is a pain
- 15:24:21 [burn]
- cullen: for aspectratio you want to compare geometrically/exponentially. it is Euclidean but scaled to the idea of an ideal image. every new constraint does require a metric and we could debate them, but as long as it's deterministic it doesn't matter too much since you can implement your own
- 15:24:30 [burn]
- ... you can always use advanced to get what you want
- 15:24:46 [mt_]
- fluffy: this is not euclidean distance
- 15:24:59 [burn]
- ... if you don't like the definition of ideal in the standard, then use advanced
- 15:25:17 [gmandyam]
- ack gmandyam
- 15:25:23 [mt_]
- sum of logs!
- 15:25:35 [mt_]
- least squares!
- 15:25:50 [ekr]
- sin(logs)
- 15:26:08 [stefanh]
- q+
- 15:26:08 [burn]
- harald: slight preference for squaring. We say algo has to behave the same as what's specified, but doesn't say you have to use the algo given. This is quite implementable in practice.
- 15:26:22 [hta]
- q-
- 15:26:25 [burn]
- ... with real drivers and real devices this is doable
- 15:26:26 [jib]
- q+
- 15:26:44 [hta]
- juberti-
- 15:26:54 [mt_]
- q- juberti
- 15:26:54 [hta]
- q- juberti
- 15:27:13 [Peter]
- Zakim, who is muted?
- 15:27:13 [Zakim]
- I see +1.425.610.aaaa muted
- 15:27:19 [burn]
- stefan: what about this large value for strong match? doesn't this make this constraint mandatory or exact?
- 15:27:23 [Peter]
- Zakim, unmute aaaa
- 15:27:23 [Zakim]
- +1.425.610.aaaa should no longer be muted
- 15:27:40 [Peter]
- q+
- 15:27:53 [juberti]
- q+
- 15:28:57 [burn]
- cullen: for some constraints, such as the id, we essentially want ideal to mean exact. regarding squaring the distances that's probably not a big sticking point
- 15:29:04 [stefanh]
- ack me
- 15:29:31 [burn]
- jib: not sure we need close or greater. For example, on framerate why not just CLOSE?
- 15:29:44 [burn]
- peter: couldn't think of a reason
- 15:30:14 [burn]
- (several folks spoke at once in reply)
- 15:31:02 [jib]
- q-
- 15:31:51 [burn]
- Peter: okay with framerate being the same as aspectratio or height/width
- 15:32:20 [ekr]
- q+
- 15:32:33 [burn]
- ... also, the intent was that the exact alg doesn't have to be implemented, but result must be same
- 15:33:10 [ekr]
- q-
- 15:34:19 [burn]
- Justin: on distance min, we considered Euclidean but switched to linear for simplicity. This wolud be a minor change. On dynamic range, there is no trivial solution. best is for app to try something and see what happens. If app requests a certain framerate and resolution from device, it just needs to check what comes back from device and adjust accordingly.
- 15:34:46 [burn]
- ... typically you DO have enumerated modes. It works quite well. That's my implementer feedback.
- 15:35:07 [burn]
- (back to slides)
- 15:35:17 [fluffy]
- q?
- 15:35:36 [burn]
- ack Peter
- 15:35:41 [burn]
- ack juberti
- 15:36:12 [burn]
- Peter: this is easy to try out in a spreadsheet
- 15:37:52 [burn]
- ... there were some questions raised on the list, shown here in the slides
- 15:38:10 [burn]
- (skipping over advanced expansion option at group request)
- 15:38:33 [ekr]
- q+
- 15:38:54 [burn]
- jib: I like min distance much better than advanced expansion but also like no ideal
- 15:39:11 [fluffy]
- q+
- 15:39:14 [burn]
- ekr: if this is what's required to get ideal, then let's get rid of idea altogether
- 15:39:29 [burn]
- martin: i suggest getting rid of advanced instead
- 15:39:51 [burn]
- jib: i meant that I like impl-spceific version as well, not removing ideal altogether
- 15:40:24 [juberti]
- q+
- 15:40:27 [burn]
- cullen: we have to keep advanced because of use cases. don't want ideal with non-deterministic behavior. we can remove it, but don't leave it in and have nondeterministic behavior
- 15:40:30 [ekr]
- q-
- 15:40:34 [fluffy]
- q-
- 15:41:43 [burn]
- justin: not sure how to solve continuous ranges with advanced since it doesn't give a target, and I think ideal solves 99% of cases people want without using advanced, so it's important to keep
- 15:42:56 [burn]
- ... think ideal is the best thing we have so far for dealing with parameters that are interrelated. ideal needs to be deterministic.
- 15:43:09 [juberti]
- q-
- 15:43:44 [ekr]
- q+
- 15:44:07 [burn]
- stefan: in DC there seemed to be much support for ideal. several people are requesting ideal be deterministic.
- 15:44:24 [burn]
- ekr: yes, make ideal deterministic.
- 15:44:36 [juberti]
- q+
- 15:44:46 [ekr]
- q-
- 15:45:20 [ekr]
- I agree that this text is deterministic. I just don't like it :)
- 15:45:57 [lgombos]
- lgombos has joined #mediacap
- 15:45:59 [burn]
- harald: (consensus call) two questions: if this spec proposed for ideal clear enough that it satisfies reuqirement for determinism. Second question is whether we accept or reject it. Believe we have rough consensus on first part. Any objections to that?
- 15:46:01 [burn]
- (silence)
- 15:46:11 [gmandyam]
- QuIC is in favor of rejection
- 15:46:55 [burn]
- ... Now for call in favor or against. Several folks chiming in on IRC
- 15:47:35 [burn]
- In favor are Dan, Stefan, JIB, (missed name -- from MSFT) in addition to those who have already spoken
- 15:47:47 [mt_]
- Shijun Sun
- 15:48:10 [burn]
- harald: believe we have rough consensus to go ahead. EKR said he could live with it. Giri?
- 15:48:37 [burn]
- Giri: don't understand what this adds, but if chairs call rough consensus then so it is.
- 15:48:49 [ekr]
- harald: if you think there is consensus, can you please formally call it?
- 15:49:00 [burn]
- harald: formal objections are permitted in W3C, are you doing that?
- 15:49:41 [burn]
- giri: i don't understand how min distance proposal happened and this approach isn't sufficiently future-proofed. Not sure it addresses real use cases.
- 15:50:16 [burn]
- ... no objective comparison of algorithms.
- 15:50:35 [juberti]
- q+
- 15:50:36 [burn]
- Stefan: i hear you saying there could be another algorithm.
- 15:51:37 [burn]
- Giri: it mandates deterministic behavior which is not future proof. ideal is fairly new, not clear we understand it well enough
- 15:52:03 [burn]
- ... will not raise formal objection, but caution group against adding features at this point.
- 15:52:43 [fluffy]
- q?
- 15:53:49 [gmandyam]
- q+
- 15:54:19 [burn]
- justin: we covered rationale for ideal in dc. today we attempted to explain how it works. it's pretty simple. I don't understand the advanced use cases and thus consider ideal essential for developers. If you need something beyond ideal, advanced exists.
- 15:54:21 [jib]
- +1
- 15:54:22 [juberti]
- q-
- 15:54:41 [mt_]
- i agree with juberti on this; advanced is merely a poor substitute for programmable selection
- 15:54:52 [burn]
- giri: record the decision and take it to teh mailing list so we can move on.
- 15:55:01 [gmandyam]
- ack gmandyam
- 15:55:10 [jib]
- mt_: agree with mt and justin on removing advanced
- 15:55:30 [burn]
- harald: let's go ahead with min distance version of ideal. further comments would need to be made there.
- 15:55:30 [adam]
- Zakim, who is noisy?
- 15:55:42 [Zakim]
- adam, listening for 10 seconds I heard sound from the following: Dan_Burnett (42%), +1.425.610.aaaa (43%), [Mozilla] (22%)
- 15:55:43 [hta]
- burn: there = on the mailing list
- 15:56:02 [adam]
- Zakim, mute +1.425.610.aaaa
- 15:56:02 [Zakim]
- +1.425.610.aaaa should now be muted
- 15:56:24 [Peter]
- Sure. Sorry about that.
- 15:57:11 [burn]
- harald: Chairs have declared that there is rough consensus to go ahead with the min distance version of ideal and that further comments would need to be made on the mailing list.
- 15:57:16 [ekr]
- thank you
- 15:57:29 [Peter]
- Zakim, unmute aaaa
- 15:57:29 [Zakim]
- +1.425.610.aaaa should no longer be muted
- 15:57:53 [stefanh]
- scribenick stefanh
- 15:58:06 [fluffy]
- sorry but I need to drop at this pont
- 15:58:13 [Zakim]
- -fluffy
- 15:58:14 [stefanh]
- Harald to talk about bug resolution
- 15:58:23 [ekr]
- For future reference, if you do "RESOLVED: " Zakim treats it specially
- 15:58:32 [stefanh]
- refering to slides sent out earlier: http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/att-0018/August_Media_Capture_Bug_Walkthrough__1_.pdf
- 15:58:54 [stefanh]
- Most bugs are about making sure text is clear and consistent
- 15:59:05 [stefanh]
- ...called out two bugs for discussion
- 15:59:08 [ekr]
- Or rather RRSAGENT
- 15:59:37 [stefanh]
- ...does anyone want to call out any other bug from list
- 16:00:00 [stefanh]
- How long does permissions persist? See slide
- 16:00:57 [ekr]
- q+
- 16:01:09 [stefanh]
- ....permission about read labels of devices you've had access to the label too. Should the app be allowed to read labels after closing all devices?
- 16:01:29 [stefanh]
- ....finger-printing related.
- 16:02:38 [Zakim]
- - +1.425.610.aaaa
- 16:02:56 [stefanh]
- Ekr: we should remove label access when closing
- 16:03:11 [stefanh]
- ...for consistency.
- 16:04:08 [stefanh]
- Decision: label permissions persist until all devices are closed
- 16:04:10 [Zakim]
- + +1.425.610.aaff
- 16:05:00 [stefanh]
- Next: 22251 error codes when no devices are available (or some other thing hinders)
- 16:05:17 [stefanh]
- ...proposal in slide
- 16:05:25 [stefanh]
- ...OK?
- 16:05:54 [stefanh]
- MT: how is source unavailable different from not getting aceess
- 16:06:10 [stefanh]
- ...and do we want to make the distinction?
- 16:06:24 [Jim_Barnett]
- q+
- 16:06:29 [stefanh]
- hta: there is a difference (elaborating)
- 16:07:01 [stefanh]
- MT: do we want to expose this to the app (for good and bad)? What info can the app get that is sensitive?
- 16:07:37 [stefanh]
- Jim: in the past we said the app should not know (but that was a loooong time ago)
- 16:08:13 [stefanh]
- Decison: implement proposal
- 16:08:38 [stefanh]
- hta: next slide about how bugs are handled
- 16:09:24 [stefanh]
- ...next slide about how people can help out resolving bugs
- 16:10:32 [stefanh]
- Minutes from alst meeting (June 25) approved.
- 16:10:40 [stefanh]
- s/alst/last/
- 16:11:11 [jib]
- my slides: https://docs.google.com/presentation/d/1pql9zGhtX8r84qdnGFuSZM0aOMOHBxXVbkJsXwbCI0k/edit#slide=id.p
- 16:11:49 [stefanh]
- AoB: jib talk about "bare"
- 16:12:04 [stefanh]
- jib: talking through slides
- 16:12:20 [stefanh]
- ....meaning of word "constraint"
- 16:12:31 [stefanh]
- ...slide 3 look at JS code example
- 16:13:08 [stefanh]
- ....slide 4
- 16:13:49 [stefanh]
- ....slide 5
- 16:13:54 [ekr]
- q+
- 16:14:25 [stefanh]
- ....ideal is the only thing that stands out
- 16:14:37 [Jim_Barnett]
- q-
- 16:15:07 [stefanh]
- Ekr: I don't think I agreed to floating point expressions
- 16:15:17 [stefanh]
- jib: sorry for bad example
- 16:16:06 [adam]
- q+
- 16:16:09 [stefanh]
- .... slide 6
- 16:16:19 [ekr]
- q-
- 16:17:38 [stefanh]
- adam: I have an issue with removing the exact keyword - we may express constraints as objects in the future, would mean ambiguity
- 16:18:02 [stefanh]
- jib: have not seen a proposal for multi prop constraints before
- 16:18:26 [stefanh]
- ...can be figured out
- 16:19:23 [mt_]
- fwiw, I'm with jib on this, aside from the point about removing exact
- 16:19:26 [stefanh]
- ...slide 7 min max can been different things depending on where they are applied
- 16:19:36 [mt_]
- the aspect ratio thing needs to be solved
- 16:20:14 [stefanh]
- ....questions?
- 16:20:24 [hta]
- q?
- 16:20:33 [adam]
- q-
- 16:20:43 [stefanh]
- ...were are not tied to ideal
- 16:20:48 [juberti]
- q+
- 16:20:57 [stefanh]
- s/were/we're/
- 16:21:26 [ekr]
- q+
- 16:21:36 [hta]
- q+
- 16:22:17 [stefanh]
- justin: app developer perspective, would be surprised if things fail 'cause a bare value is interpreted as exact
- 16:22:26 [Peter]
- q+
- 16:22:42 [stefanh]
- q+
- 16:23:01 [stefanh]
- jib: naive people seem to thing "mandatory" and not ideal
- 16:23:14 [stefanh]
- s/thing/think/
- 16:23:21 [mt_]
- q+
- 16:23:58 [stefanh]
- juberti: if you move to a new computer you could be surprised
- 16:24:43 [stefanh]
- jib: the developer should use ideal or advanced
- 16:25:05 [stefanh]
- juberti: not the simple apps
- 16:26:48 [stefanh]
- ekr: agree with justin, lingusitic arguments not convincing
- 16:27:37 [stefanh]
- hta: jib introduced foot gun - this is a foot gun
- 16:28:06 [stefanh]
- jib: foot-gun was different
- 16:28:43 [mt_]
- calling back to previous... https://www.w3.org/Bugs/Public/show_bug.cgi?id=26526
- 16:28:52 [stefanh]
- Peter: prefer removing bare values
- 16:29:14 [stefanh]
- stefanh: agree with Peter - my point
- 16:29:19 [mt_]
- q-
- 16:29:25 [hta]
- ack juberti
- 16:29:27 [hta]
- ack ekr
- 16:29:29 [hta]
- ack hta
- 16:29:31 [stefanh]
- mt_: foot-gun argument works for me too
- 16:29:33 [hta]
- ack peter
- 16:29:36 [hta]
- ack stefanh
- 16:29:37 [stefanh]
- ack me
- 16:30:01 [stefanh]
- jib: unfortunate to remove "bare" (lost argument why)
- 16:30:18 [mt_]
- chairs, I formally request a consensus call on this
- 16:32:52 [stefanh]
- hta: only one arguing for bare meaning exact is jib
- 16:33:40 [stefanh]
- dan: do we accept jib's proposal?
- 16:34:19 [ekr]
- We are out of time.
- 16:34:25 [stefanh]
- hta: currently bare means ideal, we have a new proposal to make it mean exact
- 16:34:55 [stefanh]
- ...anyone except jib supporting the change?
- 16:35:00 [stefanh]
- ...silence
- 16:35:18 [stefanh]
- ...result: no concensus to change, so bare will mean ideal
- 16:35:41 [stefanh]
- chairs declared this as consensus.
- 16:35:44 [Zakim]
- -[Mozilla]
- 16:35:52 [Zakim]
- -Dan_Burnett
- 16:35:53 [Zakim]
- -stefanh
- 16:35:54 [Zakim]
- -gmandyam
- 16:35:54 [Zakim]
- -hta
- 16:35:56 [Zakim]
- -[Microsoft]
- 16:35:56 [Zakim]
- -Jim_Barnett
- 16:35:57 [Zakim]
- - +1.425.610.aaff
- 16:35:59 [Zakim]
- -jib
- 16:36:16 [Zakim]
- -adam
- 16:36:27 [hta]
- hta has left #mediacap
- 16:37:10 [Zakim]
- - +91.22.39.14.aadd
- 16:37:12 [Zakim]
- UW_MdCap()11:00AM has ended
- 16:37:12 [Zakim]
- Attendees were Dan_Burnett, stefanh, adam, +1.425.610.aaaa, +1.408.421.aabb, +1.267.934.aacc, jib, +91.22.39.14.aadd, gmandyam, [Mozilla], [Microsoft], fluffy, Jim_Barnett,
- 16:37:12 [Zakim]
- ... +47.41.44.aaee, hta, +1.425.610.aaff
- 16:51:09 [ekr]
- ekr has joined #mediacap
- 16:52:57 [ekr]
- ekr has joined #mediacap
- 18:31:24 [Zakim]
- Zakim has left #mediacap
- 19:07:12 [fjh]
- fjh has joined #mediacap
- 19:08:20 [fjh]
- fjh has left #mediacap
- 19:12:27 [lgombos_]
- lgombos_ has joined #mediacap
- 19:13:55 [jib]
- jib has joined #mediacap
- 19:22:35 [jib]
- jib has joined #mediacap
- 20:00:36 [jib]
- jib has joined #mediacap
- 20:06:37 [lgombos_]
- lgombos_ has joined #mediacap
- 20:17:13 [jib]
- jib has joined #mediacap
- 20:32:44 [lgombos_]
- lgombos_ has joined #mediacap
- 20:53:58 [jib]
- jib has joined #mediacap
- 21:02:58 [lgombos_]
- lgombos_ has joined #mediacap
- 21:08:36 [jib]
- jib has joined #mediacap
- 21:14:17 [ekr]
- ekr has joined #mediacap
- 21:49:37 [fjh]
- fjh has joined #mediacap
- 21:52:08 [lgombos__]
- lgombos__ has joined #mediacap
- 22:08:22 [jib]
- jib has joined #mediacap
- 22:11:37 [lgombos__]
- lgombos__ has joined #mediacap
- 23:57:02 [lgombos__]
- lgombos__ has joined #mediacap