Time and Location
Thursday, 2007-08-09 in #adium-devl
| PDT | MDT | CDT | EDT | CEST |
| 6 PM | 7 PM | 8 PM | 9 PM | 3 AM |
Agenda
- Reducing bus factor
- Trimming the version history
- Code documentation
- SummerOfCode review
- V/V Status
- Elliott's Secret Item
- Augie's One More Thing
Log
18:00:40: <The_Tick> alright, let's begin 18:00:47: <The_Tick> first item, reducing bus factor 18:01:00: <The_Tick> I started this thread on TheDayOfManyEmailsFromTheTick 18:01:22: <The_Tick> we have multiple bus factors, within code and within administration 18:01:45: <The_Tick> we have bits of code nobody dares touch due to code ownership type situations, things like that 18:01:52: <Mac-arena> Which? 18:01:54: <The_Tick> and then evan and I are pretty hefty bus factors 18:02:08: <Mac-arena> The only code I don't touch, I don't touch because I have NFI what it does or how it does it :) 18:02:13: <The_Tick> Mac-arena: I don't know off hand, but think about when adam left 18:02:14: <Mac-arena> (which, really, is most of it) 18:02:15: <sholt> heh 18:02:20: <The_Tick> or sholt even 18:02:41: <Mac-arena> AIH is pretty well-written. I don't think we've had any problem maintaining it. 18:02:45: <The_Tick> I'm sure there is code that nobody knew about for a year after adam left that only he know about 18:02:54: <The_Tick> like intimately knew 18:03:03: <The_Tick> I'm advocating more docs basically 18:03:06: <The_Tick> and unit testing 18:03:10: <Mac-arena> The obvious solution is: Comment, comment, comment! 18:03:19: <Mac-arena> Yeah, and header docs, and unit-testing 18:03:24: <proton> well commenting doesn't magically fix things 18:03:38: <durin42> good comments help a lot 18:03:38: <proton> designing stuff with an actual well-defined API 18:03:42: <proton> that can be unit tested 18:03:44: <proton> that is what helps 18:03:46: <Mac-arena> Matt's been doing really well with the unit testing, actually. It has about 439% more test coverage than the rest of Adium (and remember, 77.3% of statistics are made up). 18:04:03: <The_Tick> proton: ya, that's part of it 18:04:27: <Mac-arena> 1. Document the API. 2. Write tests that assert that the API does what it is documented to do. 3. (for new APIs) Implement the API. 18:05:08: durin42 nods, this is what happens at google 18:05:34: <proton> yep, once you've got the API defined then the only comments really needed in the code (not the headers, the code) is where something isn't obvious why it does something in a certain way 18:06:02: <Mac-arena> I'm actually more verbose than that. I write a lot of comments, so that code can be easily skimmed. 18:06:15: <Mac-arena> Basically, summarize nearly every paragraph of code in English for easy reading. 18:06:21: <Mac-arena> (and sanity-checking) 18:06:44: <Mac-arena> When tracking a bug, you actually read the code, and compare to the stated intent. If you have a mismatch, you have a problem that needs fixing, whether it's your bug or not. 18:07:31: <Mac-arena> . 18:06:46: :Server: eitanko (n=eitan@cpe-72-225-237-159.nyc.res.rr.com) joined #adium-devl 18:07:33: <eitanko> thanks for the reminder, Peter 18:07:40: <Mac-arena> eitanko: You're welcome. Who're you? :) 18:08:10: <proton> you've got to be careful with over-commenting code though Mac-arena. if you get a mismatch between the code and the comment how do you know which one is right? 18:08:22: <Mac-arena> proton: You find out. :) 18:08:24: <eitanko> i'm eitan. im supposedly helping out with vv, but ive been a bit busy with work lately 18:08:46: <Mac-arena> eitanko: Ah. That explains why I don't know you, as I'm not on the VV list. 18:09:08: <Mac-arena> proton: A mismatch is always a problem in at least one, if not both. Far better to have a mismatch than to have an undetected bug. 18:09:12: <eitanko> Mac-arena: was here a lot more often back in June 18:09:27: <Mac-arena> eitanko: I was here a lot more often back in... um... 2006. 18:09:53: <eitanko> Mac-arena: well please to meet you anyways 18:09:59: <Mac-arena> Likewise :) 18:10:03: <durin42> focus people 18:10:04: <Mac-arena> The_Tick: Any other bus factors? 18:10:06: <manung> in my experience you won't want to write too much comments, because then you are too busy maintaining comments, when you should be maintaining the code 18:10:45: <Mac-arena> manung: Maintaining the comments helps you maintain the code, though. 18:11:18: <proton> yeah, over commenting is a very common mistake when people go "Oh no! We have no comments" or "Oh no! We've only got one person who knows about this code" or even "Oh no! My CS course said I should do things this way" 18:11:29: <Mac-arena> As I said, a mismatch is a problem in at least one, if not both. If the comment goes out of date, then of course you should update it, but you should be in the habit of keeping your comments up-to-date anyway. 18:11:33: <manung> Mac-arena: true, but I like to focus on making the code more readable, instead of wrting comments that echo what the code does 18:11:38: <Mac-arena> If the code goes out of date, then what are you doing rewriting comments and not code? 18:11:58: <Mac-arena> manung: I'm not arguing that it should be a substitute for readable code, or that you should comment EVERYTHING. int i = 0; needs no explanation. 18:12:09: <Mac-arena> (Or at least, not simply "Initialize i to 0") 18:12:23: <Mac-arena> Comments explain why, not how. 18:12:38: <eitanko> Mac-arena: strongly agree 18:12:48: <manung> Mac-Arena: yep, just saying there is a balance that needs to be made 18:12:57: <Mac-arena> manung: Of course. BTW, tab completes nicks. 18:13:23: <manung> Mac-arena: cool, :-) 18:13:31: <hal2k> Mac-arena: not in adium :P 18:13:41: <Mac-arena> hal2k: Adium doesn't support IRC. ;) 18:13:56: <Erik006_> mac-arena: really? 18:14:05: <Mac-arena> Erik006_: Not yet. 18:14:08: <Erik006_> afaik it does 18:14:14: <Mac-arena> (Half-working plug-ins notwithstanding) 18:14:29: <hal2k> not enabled by default 18:14:37: <Mac-arena> Not even shipped by default. 18:14:38: <The_Tick> sorry guys 18:14:53: <The_Tick> wife decided she needed to talk to me about something 18:14:59: <The_Tick> anyhow, what're we on? 18:15:01: <jas8522> uh oh ;) 18:15:14: <Erik006_> anyway, another thing: I'm not sure about the rest of you, but I have the tendency to work on specific parts of code i'm familiar with.. does anyone else do this? 18:15:25: <The_Tick> Erik006_: everyone does 18:15:25: <Mac-arena> The_Tick: Comments 18:15:34: <Mac-arena> Erik006_: Familiarity brings commits. 18:15:34: <The_Tick> Erik006_: watch the poisonous people talk 18:15:38: <The_Tick> they address this 18:15:47: <Erik006_> i watched it 18:15:49: <Erik006_> the point being 18:15:50: <The_Tick> it's fine to be more familiar with one bit of code 18:16:00: <The_Tick> but nobody owns any specific code for instance 18:16:05: <proton> Well summary of the bus factor for code: need a definition of the API for various classes. Need appropriate level of commenting. Need Unit Tests of APIs. 18:16:08: <The_Tick> and you should branch out to other bits 18:16:09: <Erik006_> if we encourage people to work on a variety of things, we get a lower bus factor 18:16:20: <Mac-arena> Erik006_: Indeed. 18:16:25: <The_Tick> Erik006_: ya, that's the idea 18:16:28: <Mac-arena> proton: + Developers should work on unfamiliar code. 18:16:53: <durin42> t 18:17:02: <hal2k> wasn't there a unit test SoC project? 18:17:03: <Mac-arena> durin42: u 18:17:03: <durin42> (ignore that) 18:17:09: <Mac-arena> hal2k: Yeah, last year. 18:17:10: <The_Tick> alright, I think we're done 18:17:12: <Mac-arena> Not sure how that went. 18:17:14: <The_Tick> with this bit 18:17:26: <durin42> The_Tick: I'll be back in a minute, I *do* want to be here for trimming history talk 18:17:31: <The_Tick> alright 18:17:37: <durin42> The_Tick: so plz delay that item if I don't make it back right away :) 18:17:40: <edr1084> Mac-arena: it was this year and he got hired by apple so he couldn't do it 18:17:48: <The_Tick> peter, you are up 18:17:49: <Mac-arena> edr1084: Ah, OK 18:17:52: <proton> just remember that unit tests are no good unless there's actually an API to test :) 18:17:54: <Mac-arena> The_Tick: By how much? 18:17:57: <The_Tick> http://trac.adiumx.com/wiki/Doxygenation 18:18:04: <Mac-arena> Oh, OK. 18:18:07: <Mac-arena> Um, please do it? 18:18:10: <The_Tick> third topic 18:18:13: <Mac-arena> :D 18:18:22: <Mac-arena> I still have AIUtilities assigned to me. 18:18:32: <Mac-arena> Guys, go to Doxygenation and assign yourself something 18:18:48: <The_Tick> do we have a style guide for it? 18:18:49: <Mac-arena> Any one or more single classes. 18:18:53: <Mac-arena> The_Tick: Yes 18:19:01: <The_Tick> oh right, now I see it 18:19:12: <Mac-arena> http://trac.adiumx.com/wiki/Doxygenation 18:19:18: <The_Tick> so durin42 wants to run a program against the codebase at some point 18:19:24: <Mac-arena> Feel free to take stuff from AIU, too. I'm not greedy. 18:19:26: <The_Tick> and find out which methods aren't documented 18:19:32: <The_Tick> and have that posted on the website 18:19:46: <Mac-arena> The_Tick: I think the list of documented methods is shorter ;) 18:19:55: <Mac-arena> This actually ties in well with the "work on unfamiliar code" point. 18:19:57: <The_Tick> yea, but the idea is this program is run nightly 18:19:58: <Mac-arena> What you can do is 18:20:10: <Mac-arena> Get out a notepad (paper or bits). 18:20:10: <The_Tick> guess it could do both 18:20:20: <Mac-arena> Start documenting a class in the header using Doxygen comments. 18:20:38: <Mac-arena> Refer to the implementation to determine what a method is supposed to do and expand your explanations. 18:20:57: <Mac-arena> And if you see anything that looks hairy or like a bug or worth profiling (etc.), make a note. 18:21:16: <Mac-arena> And then when you're done documenting, refer to your notes and start cleaning up/fixing up/profiling the code you just documented. 18:21:25: <The_Tick> general rule of thumb from iser was that if you don't understand it in an hour 18:21:29: <The_Tick> it's a candidate for review 18:21:33: <Mac-arena> You could even include a list of tests that would be worth running. 18:21:47: <Mac-arena> The_Tick: Yeah, but writing documentation can really accelerate that process. 18:21:55: <Mac-arena> It forces you to come up with an explanation for the code. 18:21:57: <proton> you've got to remember that not every routine in a class should necessarily be part of the API 18:22:01: <Mac-arena> You create a feedback loop, basically. 18:22:02: <proton> there may be private methods... 18:22:06: <Mac-arena> proton: Right. You work from the header. 18:22:24: <Mac-arena> You don't look in the implementation and document *every* method therein. You start from the header and document the methods declared there. 18:22:25: <hal2k> adium should adapt the new feature for private methods soon 18:22:32: <hal2k> (part of ObjC 2.0) 18:22:43: <Mac-arena> You use the implementation only to expand your documentation in the headers (e.g. "may be slow for unsorted lists"). 18:22:45: <Mac-arena> +, 18:22:53: <proton> hal2k: that depends on your definition of "soon" 18:22:55: <The_Tick> edr1084: you around? 18:23:05: <edr1084> yeah 18:23:10: <The_Tick> kk 18:23:19: <The_Tick> Mac-arena: we done with this topic? 18:23:21: <hal2k> proton: after 10.5 release 18:23:58: <Mac-arena> I think so. I'll just repeat: Everybody with any ability to understand Obj-C (or wanting an excuse to learn it by doing) should go to the Doxygenation page and assign themselves something. 18:24:01: <Mac-arena> http://trac.adiumx.com/wiki/Doxygenation 18:25:11: <The_Tick> edr1084: you're up 18:25:14: <The_Tick> V/V update 18:25:17: <edr1084> kk 18:25:23: <edr1084> so basically two main things 18:25:36: <edr1084> #1 sean issued us a challange 18:26:25: <edr1084> if we can get a demo that will capture from a web cam and display it slightly angled and reflected (a la ichat) he'd sit down and within a week's time give us working jingle in libpurple 18:27:04: durin42 returns 18:27:05: <edr1084> #2 18:27:18: <edr1084> we're looking at taking v/v 10.5+ 18:27:27: <durin42> +1 18:27:39: <Mac-arena> 10.5+, or QT 7.2+? Keeping in mind that QTKit Capture is semi-public since 7.2. 18:27:48: <The_Tick> 10.5 18:27:52: <Mac-arena> Why? 18:27:54: <hal2k> it's not public, but it's available 18:28:01: <Mac-arena> hal2k: Hence, semi-public. 18:28:06: <edr1084> elliott: you still around? 18:28:06: <Mac-arena> All you need is to class-dump it. 18:28:06: <The_Tick> Mac-arena: how long do you think it's going to take us to do V/V? 18:28:09: <elliott> aye 18:28:16: <Mac-arena> The_Tick: No idea, having never done it :) 18:28:30: <edr1084> elliott: care to weigh in? 18:28:33: <edr1084> :) 18:28:33: <The_Tick> my easy estimate is 2 years from when I contacted edr1084 about it 18:28:37: <Mac-arena> Working from class-dumped headers, so it's probably safe to assume that we wouldn't have it until very close to Leopard. 18:28:46: <Mac-arena> s/ so/ 18:28:50: <The_Tick> anyhow, let's let elliott explain 18:28:52: <proton> I don't think you'll have VV done before Leopard's release so I wouldn't be worried if it was Leopard-only 18:29:07: <hal2k> my unscientific guess is a week of work, plus a week for sean to do his 18:29:10: <proton> it's a big enough new feature that people can put up with it being 10.5 only 18:29:24: <elliott> Mac-arena: The vast majority of people on the team have actually -seen- the QTKit capture API. 18:29:40: <elliott> because they have Leopard access. 18:30:07: <elliott> If we class-dump the API, we'd basically have to "forget" all of that knowledge. 18:30:08: <hal2k> elliott: I have access, but not looked at QTKit yet 18:30:15: <Mac-arena> I'm with hal2k. 18:30:23: <elliott> and attempt to do that from scratch. 18:30:34: <elliott> Yeah, but there's no way you can -prove- you haven't looked at it. 18:30:41: <durin42> he's right 18:30:42: <Mac-arena> True. 18:30:44: <durin42> legally it's messy 18:30:46: <hal2k> my understanding is that the C-based QuickTime API is phased out, QTKit is the only one that should be used 18:30:50: <elliott> This is another case of us avoiding NDA mess. 18:31:02: <durin42> we have two choices: work on it, and get it working on leppr and then hold the code until then 18:31:11: <elliott> So in the interest of not stalling V/V development until October, we're pushing it until Leopard. 18:31:12: <durin42> or we wait until leppr 1.0 18:31:13: <hal2k> we don't have to release any source until october 18:31:30: <durin42> s/don't have to/can't/ 18:31:56: <durin42> actually 18:31:59: <durin42> on my 10.4 machine 18:32:09: <durin42> class-dumping the QTKit framework appears to give decent-ish info 18:32:35: <durin42> can we work on a non-in-tree capture app to meet sean's challenge? 18:32:41: <Mac-arena> durin42: Sure. 18:32:43: <elliott> However, Sean's been gracious enough to allow us to keep the source for the demo closed. 18:32:52: <elliott> since it will be using NDA'd API. 18:32:54: <hal2k> good objc APIs don't need a reference 18:33:01: <Mac-arena> elliott: The documentation is NDA'd. 18:33:06: <edr1084> indeed, I specifically asked about that and he was willing to trust us if we tell him it works 18:33:10: <Mac-arena> Anything we get from class-dump is public, which means it's no longer covered. 18:33:28: <The_Tick> anything class-dump is liable to change 18:33:32: <The_Tick> this is not something we should be doing 18:33:34: <durin42> I suggest we use a DVCS (mercurial++) and do this 18:33:35: <The_Tick> we did it with growlmail 18:33:37: <The_Tick> and that's a PITA 18:33:42: <elliott> Mac-arena: There is no distinction if you have access whether you are working off the NDA'd documentation or class-dump docs. 18:33:45: <The_Tick> we're not doing it this way Mac-arena 18:33:55: <durin42> behind closed doors 18:33:57: <durin42> then at the end 18:34:01: <durin42> we can open the source 18:34:08: <Mac-arena> elliott: How isn't there? 18:34:26: <The_Tick> Mac-arena: this is how it's being done 18:34:35: <The_Tick> I personally want 1.4 to be 10.5+ only 18:34:47: <The_Tick> instead of us messing with it again like the 10.3 mess 18:35:12: <elliott> Precisely, if you have access, you can be assumed to be using the docs, regardless of whether we have class-dumped it or not. 18:35:43: <Mac-arena> elliott: Sucky. 18:35:52: <elliott> Thems the breaks. 18:36:01: <edr1084> so here's the other thing 18:36:11: <hal2k> I'd be fine with going closed until leopard release 18:36:13: <edr1084> eitanko: you were one without access to leopard right? 18:36:20: <eitanko> edr1084: yup 18:36:37: <The_Tick> is eitanko critical to this? 18:36:51: <The_Tick> does he need access like yesterday? 18:37:04: <edr1084> I'd still like to be able to give you guys a chance to contribute if we can find something 18:37:31: <elliott> The actual NSOpenGLView stuff for the reflection and whatnot should all be 10.4 kosher. 18:37:40: <eitanko> well leopard is needed for the QTKit stuff. aren't there other things to do besides capture and playback? 18:38:11: <hal2k> OpenGL hasn't changed 18:38:21: <proton> you only the reflection stuff if you're doing a multi-party chat 18:38:26: <hal2k> eitanko: encoding is required 18:38:36: <The_Tick> there's some oss code for the reflection stuff I think 18:38:37: <proton> you just have the video in a window for single party chat (look at iChat) 18:38:41: <hal2k> proton: you can do that for one-on-one, too 18:38:53: <hal2k> The_Tick: doing reflections is a three-liner in opengl 18:38:57: <edr1084> proton: that was part of sean's challenge whether WE need it right away or not 18:39:02: <The_Tick> hal2k: there we go 18:39:02: <hal2k> The_Tick: I can do that 18:39:04: <The_Tick> we'll have OSS 18:40:34: <elliott> So anyhow, I'll be working on the Gstreamer/Quicktime stuff over the next week or two, and time permitted should be able to assemble the things we need for the demo fairly easily. 18:40:51: <The_Tick> being that sean is not nda'd 18:40:58: <The_Tick> we'll have to wait until 10.5 is out 18:41:01: <The_Tick> assumably 18:41:09: <elliott> So, if everyone involved could shoot for in that time frame to at least prototype your stuff. 18:41:18: <elliott> He said we could show him a demo without giving him the source. 18:41:19: <Mac-arena> The_Tick: Only if he wants us to prove it to him with an app. 18:41:36: <elliott> Eric talked to him about our position. 18:41:37: <edr1084> he's cool with something as simple as a screenshot 18:41:37: <zac> meeting! 18:41:40: <elliott> So that's taken care of. 18:41:53: <elliott> I'd like to do a video, but screenshots are fine too. 18:42:06: <elliott> Other people can also be doing research for AIM video related stuff 18:42:07: <The_Tick> how is alan coming with oscar vv? 18:42:13: <elliott> since Jingle will only apply to Jabber. 18:42:20: <durin42> The_Tick: are we sure sean is not nda? 18:42:24: <edr1084> The_Tick: alan is assumed to be MIA 18:42:26: <The_Tick> durin42: find out? 18:42:29: <The_Tick> edr1084: alright 18:42:31: <hal2k> elliott: I'll be gone for two weeks starting on sat, but I can do the opengl-part afterwards 18:42:40: <elliott> hal2k: righto, we talked about that. 18:42:46: <edr1084> The_Tick: he's got some other things going on so I haven't heard a ton from him 18:42:53: <Mac-arena> What is Sean's challenge, exactly? Just to create a $3000 mirror? 18:42:54: <hal2k> just get me a nice picture :) 18:42:55: <The_Tick> edr1084: ask him if he can send you what he has 18:42:58: <The_Tick> documentation and other stuff 18:43:00: <durin42> it seems like GOOG should have a select membership or something 18:43:02: <elliott> Mac-arena: pretty much. 18:43:10: <Mac-arena> Hmmm 18:43:11: <proton> durin42: the Apple NDA doesn't let oyu talk to people about NDA stuff unless they work for the same entity as you you know... 18:43:13: <The_Tick> elliott: btw, iser had code to make a mirror in 18:43:15: <The_Tick> a year ago 18:43:16: <elliott> durin42: It depends on your department, and I doubt he has access. 18:43:26: <The_Tick> was very simple apparently 18:43:40: <elliott> The_Tick: I believe the challenge actually specified we had to do it with GStreamer. 18:43:47: <hal2k> The_Tick: doing a mirror in opengl just means that you have to draw everything twice, the second time flipped 18:43:48: <elliott> because, yes, a mirror is quite trivial to do in OS X. 18:43:50: <durin42> yes, that's what I recall 18:43:57: <The_Tick> kk 18:44:06: <elliott> edr1084: correct me if I'm wrong though. 18:44:27: <edr1084> I'm finding his email now for the exact wording 18:44:28: <hal2k> The_Tick: do multi-texturing with an alpha-channel-only texture, and you got the mac os x-mirror style 18:44:36: <jas8522> I thought I read gstreamer as well 18:44:50: <elliott> because I believe that's what we was going to do 18:44:55: <edr1084> Bold promise: you get a demo using gstreamer that captures webcam 18:44:56: <edr1084> video and displays it tilted at an angle with a slight reflection 18:44:56: <edr1084> beneath it (http://macslow.thepimp.net/?p=127 should help!), and I'll 18:44:56: <hal2k> elliott: the question is, do we want to use coreimage/coreanimation, or just use opengl directly? 18:44:56: <edr1084> get you a working¹ -vv branch of libpurple within a week. 18:44:57: <elliott> was implement gstreamer+jingle 18:45:05: <Mac-arena> hal2k: When I say "mirror" I just mean feeding the video back to a window. 18:45:11: <hal2k> ah ok 18:45:17: <Mac-arena> Thus allowing you to gaze upon your own image with a $3000 lump of electronics. 18:45:26: <elliott> edr1084: aye there it is 18:45:29: <hal2k> Mac-arena: that doesn't matter for gstreamer, since you just have to provide the source plugin 18:45:49: <manung> http://pidgin.im/pipermail/devel/2007-July/002168.html 18:45:51: <elliott> hal2k: well, since it's QTKit, we can double the video back into an NSOpenGLView. 18:45:56: <elliott> without much trouble 18:45:59: <hal2k> Mac-arena: if you're feeding the image to your video sink or a network link is just a matter of setup 18:46:12: <hal2k> elliott: we have to use gstreamer, according to the challenge 18:46:12: <elliott> CI/CA if you can, GL if you can't. 18:46:32: <manung> Bold promise: you get a demo using gstreamer that captures webcam 18:46:32: <manung> video and displays it tilted at an angle with a slight reflection 18:46:32: <manung> beneath it (http://macslow.thepimp.net/?p=127 should help!), and I'll 18:46:32: <manung> get you a working¹ -vv branch of libpurple within a week. 18:46:39: <manung> quoted from his email 18:46:42: <elliott> hal2k: Right to feed it, but we don't have to use it to display it. 18:46:50: <edr1084> manung: already got it ;) 18:46:58: <elliott> That way we can build a nice UI around it on our side. 18:47:07: <elliott> and have it being processed into GStreamer down below. 18:47:20: <hal2k> elliott: we're not trying to do a nice UI, we're trying to fulfill the challenge :) 18:47:20: <elliott> so as far as I'm concerned, the display stuff should be all Cocoa. 18:47:32: <elliott> hal2k: Wouldn't it be trivial either way? 18:47:38: <hal2k> elliott: it should be 18:47:41: <The_Tick> hal2k: thinking of it that way is bla 18:47:48: <The_Tick> why not do it right from the beginning? 18:47:53: <durin42> +1 18:47:53: <elliott> Exactly. 18:48:03: <hal2k> The_Tick: the right way is to feed it to gstreamer for networking 18:48:13: <hal2k> the question is, do we want to use gstreamer for the local mirror? 18:48:21: <elliott> I just went over this, no. :P 18:48:25: <The_Tick> hal2k: yes 18:48:38: <elliott> The_Tick: *boggle* why? 18:48:45: <The_Tick> to fullfill the requirements... 18:48:53: <The_Tick> ok, point is 18:48:57: <The_Tick> whatever his challenge is 18:49:00: <The_Tick> that's what's happening 18:49:06: <durin42> we need gstreamer anyway 18:49:06: <The_Tick> right? 18:49:08: <elliott> But he doesn't care about the mirror, he cares that he can get the video on screen across the pipe. 18:49:12: <durin42> so we might as well do it right 18:49:26: <durin42> the mirror needs to work using gstreamer 18:49:39: <The_Tick> ok, then there's nothing to argue about 18:49:41: <durin42> because he's going to use gstreamer to serialize/deserialize to/from the network 18:49:58: <elliott> but he's not serializing/deserializing the mirror 18:50:11: <elliott> he's being fed the data directly from quicktime 18:50:26: <elliott> and quicktime+(insert apple technology here) is providing the mirror. 18:50:41: <Mac-arena> The challenge is not simply "create a mirror" 18:50:53: <Mac-arena> The challenge is "implement video that can be put into Adium" 18:50:56: <Mac-arena> The mirror is simply a test bed. 18:51:00: <elliott> correct 18:51:05: <elliott> it reflects the data we are feeding him 18:51:07: <elliott> that's all. 18:51:08: <edr1084> doesn't matter WHAT the image is, as long as it captures and displays 18:51:16: The_Tick runs off 18:51:29: <Mac-arena> The_Tick: What items remain? 18:51:30: <elliott> and more importantly, can be delivered via GStreamer to Sean. 18:52:01: <elliott> Anyhow. 18:52:08: <elliott> I added this to the agenda last minute. 18:52:12: <hal2k> ok, so we need a mirror via gstreamer now, but we don't need it in the final product 18:52:23: <elliott> I don't think we need it either time. 18:52:26: <elliott> but I'll ask Sean. 18:52:43: <edr1084> elliott: about a mirror? 18:52:52: <hal2k> gstreamer-based mirror has the pro of displaying the image just as it is sent (if configured properly) 18:53:01: <elliott> either way should do that. 18:53:25: <elliott> if configured properly. 18:53:32: <hal2k> elliott: no, the image captured from the camera is less compressed than the one sent via the network 18:53:38: <hal2k> gstreamer does the compression 18:53:47: <Mac-arena> They *both* do compression. ;) 18:53:49: <elliott> edr1084: Yeah, about whether he requires the mirror in gst or doesn't care. 18:54:00: <edr1084> nothing was said about a mirror 18:54:08: <edr1084> he wants capture and display 18:54:15: <elliott> edr1084: display == mirror 18:54:24: <Mac-arena> As I said, the mirror is just a test bed. 18:54:27: <Mac-arena> It proves that it works. 18:54:43: <Mac-arena> But we shouldn't design for the mirror; we should design for Adium. 18:54:52: <hal2k> yes 18:55:00: <hal2k> so it has to go through gstreamer 18:55:07: <elliott> which is why I contend that we should be doing the mirror Adium-side. 18:55:09: <hal2k> implement a source via quicktime 18:55:11: <elliott> ................ 18:55:12: <Mac-arena> hal2k: Well, for purple, yes. 18:55:20: <elliott> hal2k: I think you're missing something here. 18:55:26: <Mac-arena> Let's not assume the eternal presence of libpurple. :) 18:55:49: <hal2k> Mac-arena: true, but other plugins should probably use gstreamer, too 18:55:57: <hal2k> elliott: what am I missing? 18:55:59: <Mac-arena> Unless they're Mac-specific, or at least GNUSTEP. 18:56:09: <Mac-arena> Or at least not GTK+. 18:56:28: <elliott> Our API will use QTKit to capture the video and turn it into GST compatible data to be sent. QTKit is ALSO going to provide a copy of the data to an NSView to be displayed and mirrored. 18:56:35: <hal2k> gstreamer does nice things on its own 18:56:43: :Server: The_Tick_ (n=tick@adsl-70-142-154-90.dsl.hstntx.sbcglobal.net) joined #adium-devl 18:56:56: <hal2k> elliott: yes, but the second part isn't required for the testbed we want to implement 18:57:04: :Server: The_Tick has signed off (Read error: 104 (Connection reset by peer)) 18:57:08: <hal2k> elliott: since that wouldn't prove anything gstreamer-side 18:57:08: <elliott> I'm telling you it is right now. 18:57:34: <elliott> Having gstreamer show the video doesn't prove anything either. 18:57:49: <elliott> aside from us knowing how to compile gstreamer and use the osxvideo plugin. 18:57:56: <hal2k> it proves that we can feed video to gstreamer 18:58:17: <hal2k> since we assume that gstreamer does what it advertizes, it can send that video to some network peer, too 18:58:27: <elliott> Visually, the two are [should be] indistinguishable. 18:58:44: <Mac-arena> Suppose we had a radio button? 18:58:50: <Mac-arena> ( ) Direct QuickTime feed 18:58:50: <The_Tick_> no 18:58:54: <Mac-arena> ( ) GStreamer feed 18:59:00: <hal2k> Mac-arena: what for? 18:59:02: :Server: The_Tick_ is now known as The_Tick 18:59:05: <Mac-arena> hal2k: Testing both. 18:59:11: <The_Tick> guys 18:59:11: <elliott> The important part is we aren't going to show off the demo without having the conversion code in place to convert to GST and send it over the wire. 18:59:15: <The_Tick> look, what's the goal? 18:59:21: <hal2k> Mac-arena: if the gstreamer-based one works, the other one should work fine anyways 18:59:22: <Mac-arena> The QT code regardless of where it's going, and the GStreamer code as well. 18:59:50: durin42 suggests this conversation be taken out of band to the -vv list 18:59:52: <Mac-arena> hal2k: Not if we intend to keep it independent of GStreamer, so that another service plug-in could be dropped in in its place. 18:59:58: <The_Tick> fguys 18:59:58: <durin42> I have things I want to discuss 19:00:00: <The_Tick> guys 19:00:01: <The_Tick> stop 19:00:06: <The_Tick> what's the goal? 19:00:10: <durin42> we've spun for 30 minutes on this at least 19:00:13: <The_Tick> durin42: 5 mins, tops 19:00:16: <The_Tick> it's important 19:00:22: <durin42> kk 19:00:24: <elliott> To create the demo Sean wants. 19:00:31: <The_Tick> what is required for that 19:00:56: <The_Tick> specifically, doing it right so we don't redo it later either 19:01:00: <hal2k> getting a video feed to gstreamer and displaying it using some opengl-magic 19:01:05: <elliott> No. 19:01:30: <elliott> Capturing video from QTKit, displaying it on screen, and having code that can convert this to travel the wire via GStreamer. 19:01:34: <Mac-arena> Getting a video feed, showing it so we can prove we are handling the feed correctly, and sending it through GStreamer (e.g., over the wire). Not necessarily in that roder. 19:01:36: <Mac-arena> order 19:01:43: <Mac-arena> (and yes, that's basically the same as what elliott said) 19:01:46: <The_Tick> which is less code? 19:01:58: <hal2k> The_Tick: doesn't matter probably 19:02:01: <elliott> Doesn't matter. 19:02:09: <The_Tick> maintainability = less code 19:02:11: <hal2k> elliott: how are you going to test the video of the feed? 19:02:20: <The_Tick> which is better for the zealotry of proton's api magiks 19:02:39: <The_Tick> which would make him happier 19:02:47: <elliott> hal2k: Probably write tests that convert GstBuffers back into Quicktime Video. 19:03:03: <The_Tick> that's the question, off to the -vv list with you guys :) 19:03:05: <hal2k> elliott: why not display the gstbuffer directly via opengl? 19:03:06: <Mac-arena> Can a GstBuffer be layered directly on a GL pixel buffer? 19:03:13: <The_Tick> edr1084: are you recruiting people at this point? 19:03:19: <elliott> Mac-arena: I don't believe so. 19:03:19: <hal2k> Mac-arena: you have to do a copy I think 19:03:27: <hal2k> Mac-arena: but there's code for that in gstreamer 19:03:35: <edr1084> The_Tick: I'm not turing people away if they can/want to contribute 19:03:36: <elliott> Anyhow, we'll discuss in -VV. 19:03:43: <elliott> I need to go, but I wanted to show this first. 19:03:44: <The_Tick> ya, please 19:03:47: <Mac-arena> edr1084: Subscribe me please? 19:03:48: <elliott> http://myskitch.com/elliott/getinfo3-20070808-210643/ 19:03:57: <edr1084> Mac-arena: I sent you an email with the link... 19:04:01: <The_Tick> yay 19:04:03: <elliott> Prototyped new Get Info panel. 19:04:17: The_Tick wants finder style get info 19:04:17: <The_Tick> anyhow 19:04:21: <Mac-arena> elliott: YUM! 19:04:21: <The_Tick> durin42: you're up 19:04:23: Mac-arena likey 19:04:25: <durin42> ok 19:04:28: <elliott> Disclosure triangles = gross. 19:04:30: <elliott> ok bbiab 19:04:35: <durin42> so, ofri brought up truncating the version history on list 19:04:43: <durin42> I think it's a bad idea 19:04:46: <durin42> for a number of reasons 19:04:46: The_Tick too 19:04:53: <Mac-arena> durin42: Subject? 19:05:05: <hal2k> the problem he's trying to fix is that the version history is geting too large to handle 19:05:13: <durin42> Mac-arena: huh? 19:05:20: <Mac-arena> durin42: Of the email 19:05:26: <durin42> oh, ya 19:05:32: <Mac-arena> Subject: [Adium-devl] Automated changelog generation 19:05:35: <Mac-arena> Right? 19:05:39: <durin42> neg 19:05:49: <Mac-arena> Ah 19:05:50: <durin42> Subject: Version History (was Re: [Adium-devl] Community versus ego?) 19:06:10: <Mac-arena> His post: Message-Id: <C3383E0C-7C04-4D2E-962D-8D6C9D5CBF72@gmail.com> 19:06:10: <The_Tick> is this a legitimate problem? 19:06:16: <durin42> His overall point was that truncating means it'd be easier to use DVCS tools 19:06:19: <proton> http://adiumx.com/pipermail/adium-devl_adiumx.com/2007-August/003304.html 19:06:20: <durin42> which is crap IMO 19:06:33: <durin42> because all DVCS importers I've seen have a starting revision import config 19:06:38: <durin42> so if git-svn lacks that 19:06:41: <Mac-arena> !proton++ 19:06:49: <durin42> we should send a crack team of code-ninjas to fix git-svn 19:06:55: <durin42> not segment our repo 19:07:06: <Mac-arena> durin42: That may be partly what he's suggesting. Switch to $DVCS, and only import the last n revisions. 19:07:19: <durin42> Mac-arena: he was open to leaving it SVN on the server I think 19:07:27: <Mac-arena> Yeah 19:07:31: <Mac-arena> I think I was conflating his with yours 19:07:33: <durin42> in essence though, I think that SVN is a good thing for us right now 19:07:36: <The_Tick> we're not keeping svn up if we switch to another vcs 19:07:45: <durin42> esp. since 10.5 will be including svn 19:07:45: <Mac-arena> SVN's really good for GSoC, as I've stated 19:07:53: <durin42> (and svk) 19:08:03: hal2k doesn't understand the vcs frenzy currently going on 19:08:11: <hal2k> it seems like every project is using another vcs 19:08:11: <The_Tick> hal2k: linus talk 19:08:15: <durin42> also, git scares the willies out of me archiecturally at the moment 19:08:30: <The_Tick> don't bring up git in #macsb, heh 19:08:34: <The_Tick> or svn 19:08:41: <hal2k> darcs and git were the most easy ones to use for me, mtn was the most complicated one 19:08:53: <durin42> fundamentally, if we wanted to go distributed 19:08:59: <durin42> there are good ways to maintain svn as a mainline 19:09:13: <durin42> and I think that we should let people use DVCS if they want for offline commit and whatever 19:09:22: <durin42> but no truncation of server history 19:09:33: <durin42> so that's my $.02 USD 19:09:39: hal2k doesn't seen the point in going distributed 19:09:52: <The_Tick> since this topic isn't about distributed 19:09:55: <The_Tick> and more about truncated 19:10:01: <durin42> any other comments? 19:10:02: <The_Tick> where are we actually choking? 19:10:06: <proton> the only thing svn needs is a "local commit" 19:10:18: <proton> then DVCS can go die in a hole :) 19:10:32: <The_Tick> if it's a problem with the repo 19:10:35: <The_Tick> let's fix the repo 19:10:40: <durin42> there's no real problem with the repo 19:10:40: <hal2k> proton: wouldn't that essentially be a dvcs then? 19:10:42: <The_Tick> I have next week off 19:10:49: <The_Tick> and can do things then 19:11:22: <proton> hal2k: not really, you don't need all that merging rubbish that people go on with 19:11:26: <durin42> some revision numbers are borked in commit messages 19:11:27: <hal2k> The_Tick: oh btw, could you ask thomas then if he hasn't forgotten about the offer for the Adium SoC students? 19:11:30: <durin42> it'd be a nice-to fix 19:11:36: <durin42> and I think we could probably figure out a rev range 19:11:38: <The_Tick> hal2k: I sent him a todo list 19:11:40: <durin42> they're off by 3 or something 19:11:43: <The_Tick> he's kinda gone mia for a few days 19:11:53: <Mac-arena> We've had commits go AWOL before. I blame that more on the tools than the repo, though. 19:11:58: <hal2k> The_Tick: well, he promised that about a month ago... 19:12:07: <Mac-arena> "Dump and load eats revisions" != "Message history is too long" 19:12:08: <Erik006_> hal2k: afaik he hasn't .. he set me up 19:12:14: <Mac-arena> s/Message/Commit/ 19:12:21: <The_Tick> hal2k: yes, I know 19:12:23: <hal2k> The_Tick: I'm not in a hurry, I just hope he hasn't forget 19:12:27: <The_Tick> indeed 19:12:30: <hal2k> forgot* 19:12:44: <The_Tick> hal2k: it's on my list for next week 19:12:49: <The_Tick> remind me though 19:12:51: <durin42> we lost revisions? 19:12:52: <The_Tick> do you have my aim? 19:12:54: <hal2k> Erik006_: did you ask for hosting or xen? 19:13:00: <hal2k> The_Tick: nope 19:13:01: <Erik006_> hosting 19:13:02: <durin42> if we did, we should bug the svn guys 19:13:11: <hal2k> Erik006_: I asked for xen, since I already got hosting 19:13:31: <The_Tick> hal2k: you really need xen over hosting for what you're doing 19:13:32: <Mac-arena> durin42: Yeah, I've seen changeset links in Trac that go to some other revision. 19:13:56: <hal2k> The_Tick: yes, for running my xmpp server without having the nr guys killing my server once per week 19:13:56: <durin42> Mac-arena: add four to the rev number 19:13:58: <durin42> then it'll be right 19:14:04: <The_Tick> hal2k: cron :P 19:14:05: <Mac-arena> durin42: Why? :) 19:14:14: <hal2k> The_Tick: I don't have cron there right now 19:14:19: <durin42> Mac-arena: because that's what is wrong 19:14:22: <The_Tick> no, that's what they are probably doing 19:14:39: <Mac-arena> durin42: What is wrong is that four revisions either spontaneously appeared or got eaten. 19:14:49: <The_Tick> I think the meeting is done 19:14:56: <durin42> Mac-arena: IIRC that came from some weird CVS importer thing 19:14:57: <durin42> The_Tick: not quite 19:14:58: <The_Tick> if anyone here is waiting around :) 19:14:58: <hal2k> The_Tick: no, it's not on a regular basis. sometimes the openfire server goes crazy and takes 100% CPU. that's when they kill it 19:15:00: <durin42> zavislak: go 19:15:07: <durin42> The_Tick: /me has another topic 19:15:10: <durin42> reload the wiki 19:15:18: <zavislak> my turn? 19:15:23: <durin42> I just decreed it so 19:15:25: <The_Tick> durin42: is this about legal stuff? 19:15:26: <The_Tick> wait 19:15:33: <durin42> ok 19:15:36: <The_Tick> durin42: is it about legal stuff? 19:15:36: <durin42> The_Tick: speak up 19:15:44: <durin42> should we do a mail list thread/ 19:15:50: <durin42> (again, the last one died) 19:15:52: <The_Tick> we should address brian's concerns 19:15:57: <The_Tick> the email is still there 19:15:59: <The_Tick> waiting 19:16:02: <durin42> *sigh* 19:16:09: <The_Tick> I told you this a while ago 19:16:18: <The_Tick> if we're going to do adium separate, that's fine 19:16:27: <The_Tick> I'm almost happier to just go that route 19:16:36: <durin42> alright 19:16:42: <The_Tick> but sharing testing boxes is promising 19:16:46: <durin42> yeah 19:16:48: <The_Tick> anyhow, email first 19:16:52: <The_Tick> let's get that out of the way 19:16:53: <durin42> fine then :P 19:16:55: <The_Tick> thanks 19:16:58: <durin42> I was hoping to deal with this on irc 19:17:02: <The_Tick> I know 19:17:04: <durin42> can you send the email you mean to me? 19:17:12: <The_Tick> but evan and brian are not on irc now 19:17:16: <The_Tick> nor are the other project people 19:17:42: <The_Tick> let me find it 19:18:21: <The_Tick> gah, I don't know the subject name 19:18:36: <durin42> Subject: Re: Mac Open Source Foundation 19:18:38: <The_Tick> ah, found it 19:18:41: <durin42> I think 19:18:48: <durin42> forward me the specific one you mean pls 19:19:07: <The_Tick> steve asked a question about outside of the US devs 19:19:09: <durin42> alright, /me has phone call 19:19:15: <The_Tick> his email from july 2nd 19:19:31: <The_Tick> I don't think he answered the questions 19:19:38: <durin42> can you compile a list of questions you didn't feel were answered please? 19:19:44: <The_Tick> yea 19:19:47: <durin42> thanks 19:19:50: <The_Tick> I'll have it out soonish 19:19:58: The_Tick adds to todo.txt 19:19:58: durin42 hugs The_Tick 19:20:10: <The_Tick> I want it done, but I want it done right 19:20:18: <The_Tick> public forum isn't right yet :) 19:20:18: durin42 nods 19:20:39: <durin42> I'm gonna go handle the phone now, later :) 19:21:47: <The_Tick> zavislak: sorry :) 19:21:56: <zavislak> The_Tick: np :) 19:22:18: <The_Tick> top of my todo list though :D 19:22:31: Mac-arena scrolls up, having just stirred M&C 19:23:17: <Mac-arena> Ah, nothing I have to respond to 19:24:04: <The_Tick> I have one final item 19:24:07: <The_Tick> proton: your msn library 19:24:19: <The_Tick> I'd like to start getting you some help on it 19:24:27: <The_Tick> is it that far along? 19:25:15: <proton> well it hasn't changed for quite a while now, it's got a few too many magic strings and stuff in it still 19:25:51: <The_Tick> can you get it into a repo where I can have someone work with you on it? 19:25:57: <The_Tick> a private one or whatever? 19:26:08: <The_Tick> until you're ready for a checkin 19:26:49: <proton> i probably need to get it a bit further on first, get it to the stage where it can send/receive messages at least :) 19:26:57: <proton> at the moment it can login but not a whole lot more 19:27:06: <The_Tick> how long will that take? 19:27:14: <The_Tick> roughly : 19:27:16: <The_Tick> :) 19:28:12: <edr1084> we looking to move away from libpurple for msn? 19:28:26: <The_Tick> proton has this snazzy idea 19:28:33: <The_Tick> he can explain it better than I can 19:28:46: <Mac-arena> What was Elliott's Secret Item? 19:28:47: <The_Tick> but if it succeeds it'd be an option 19:28:56: <The_Tick> Mac-arena: nothing atm 19:29:19: <proton> basically i've just been playing with ways to build an instant messaging library in Obj-C that should be extensible for multiple protocols with a similar API etc 19:29:29: <proton> playing with an MSNP15 implementation at the moment 19:29:29: <edr1084> Mac-arena: it was the info pane rewrite he's working on 19:29:35: <Mac-arena> Ah 19:29:43: Mac-arena approves 19:29:47: <proton> written basically all in Obj-C :) 19:30:06: :Server: Catfish_Man (n=david@c-67-189-28-219.hsd1.or.comcast.net) joined #adium-devl 19:30:33: <jas8522> so like libpurple in Obj-C 19:30:39: <Catfish_Man> sup folks 19:30:42: <The_Tick> hey Catfish_Man 19:30:42: <Mac-arena> Catfish_Man: You arrived just in time to miss almost all of the meeting ;) 19:30:53: <proton> jas8522: but it's designed to be a protocol library, nothing more 19:30:54: <Catfish_Man> damn, I'll have to wait a bit longer next time 19:31:01: <proton> libpurple kind of dictates how the UI must work 19:31:03: <The_Tick> indeed 19:31:06: <proton> in at least some areas 19:31:07: <jas8522> ahhh 19:31:19: <The_Tick> jas8522: which makes some sense forit 19:31:26: <The_Tick> since it just finally split after 10+ years 19:31:45: <jas8522> right 19:31:58: <hal2k> proton: the problem is, either you have per-protocol implementations of the UI in the app, or the library dictates the UI 19:32:17: <jas8522> interesting - especially that you chose MSN to start with. There will be alot of demand for that 19:32:18: <hal2k> proton: adium currently has both, libpurple dictating the API, and having per-protocol implementations 19:32:18: <Mac-arena> I should rip a clip of Mitch Hedberg saying "Meeting *Adjourned*!" from Mitch All Together, so we can CTCP SOUND it at the end of every meeting. 19:32:23: <Mac-arena> Especially when Evan's in attendance. 19:32:54: <proton> hal2k: the application will have to implement things for the various parts that are protocol specific if it wants to support them 19:32:56: <elliott> Any additional thoughts on the info pane? 19:33:02: <Catfish_Man> elliott: pixplz? I missed it 19:33:08: <Mac-arena> 19:03:48: <elliott> http://myskitch.com/elliott/getinfo3-20070808-210643/ 19:33:08: <elliott> http://myskitch.com/elliott/getinfo3-20070808-210643/ 19:33:09: <hal2k> proton: that sounds fine then 19:33:10: :Server: eitanko has signed off () 19:33:21: <hal2k> proton: I hope you don't limit the API to the things MSN does :) 19:33:24: <proton> but because Obj-C is nice and dynamic we can simply check if the application implements the required methods for some feature 19:33:27: <hal2k> proton: just like Adium is limited to AIM 19:33:36: <Mac-arena> The big application icon looks a little too big, but other'n that, the whole thing is very yummy. 19:33:49: <Mac-arena> (by "too big" I mean it's crowded by the box) 19:33:58: <Catfish_Man> elliott: not a huge fan of the sunken-style NSBox, and it'd be cool to use a real NSToolbar for icon/small icon/text mode niceness 19:34:01: <Catfish_Man> otherwise looks neat :) 19:34:04: <hal2k> proton: yes, objc should be MUCH nicer for the whole thing 19:34:07: <proton> the API should be generic enough to handle basically any protocol, only reason I'm doing MSN is it's the one that seems to be most neglected in features and I understand the protocol for it in most areas :) 19:34:20: <hal2k> proton: libpurple basically re-invents lots of the stuff cocoa already does 19:34:20: <elliott> Catfish_Man: The sunken box is temporary. 19:34:23: <Catfish_Man> ok 19:34:40: <elliott> Is there an NSToolbar for the small inspector-styled items? 19:34:46: <elliott> on 10.4 19:34:49: <Catfish_Man> no 19:34:57: <elliott> shrug 19:35:00: <elliott> it's modeled after the iWork inspectors. 19:35:05: <hal2k> proton: the most critical point for implementing XMPP in such a library is to support multiple clients connected to a single account 19:35:15: <hal2k> proton: all the other protocols don't support that 19:35:18: <elliott> just larger buttons since there are less items. 19:35:34: <Catfish_Man> elliott: k 19:35:40: <proton> i've got some cool tricks like handling of incoming messages on MSN parses the type of packet and does a dynamic lookup for a class that implements it :) 19:35:51: <elliott> Catfish_Man: Unless you can convince me that someone really needs to customize their Get Info window. :P 19:35:52: <proton> hal2k: well AIM lets you have multiple connections to a single account too :) 19:35:57: <Catfish_Man> elliott: point 19:36:31: <hal2k> proton: yes, but you can't talk to them separately 19:37:08: <proton> hal2k: anyway, because it's Obj-C there's no reason you can't have a subclass of the contacts to support resources for XMPP :) 19:37:26: <elliott> Catfish_Man: The box section will be identical to what we current have there, just with the slight change of the status being text and the smaller icon to the right being the service icon 19:37:37: <hal2k> proton: I don't know if you have to take care of that in the basic API, you just have to be aware of that possibility 19:37:47: <elliott> Oh, and the Contact Name will be a hovering popup for metas 19:38:06: <hal2k> proton: for example, adium is written in objc, but there's no way to implement that without rewriting the contact controller 19:38:28: <Mac-arena> Oh, I have what could be another list item (whenever you guys are ready) 19:38:52: <proton> hal2k: yeah, well that'll be something we'll keep in mind as it's written :) 19:39:00: <The_Tick> night guys 19:39:04: <Mac-arena> The_Tick: Hold 19:39:09: <Mac-arena> You're involved in my list item ;) 19:39:11: <The_Tick> hot food 19:39:15: <Mac-arena> I have hot food too :D 19:39:21: <Mac-arena> Adium-Lite. Status? 19:39:23: <The_Tick> WIFE+HOT FOOD 19:39:26: <The_Tick> Mac-arena: dead 19:39:29: <Mac-arena> Foo. 19:39:32: <The_Tick> until I know more about cocoa 19:39:35: <The_Tick> and svn 19:39:42: <The_Tick> and it's also waiting on durin42 19:39:48: The_Tick goes to eat 19:40:11: <edr1084> does this mean we go on to SoC? 19:40:21: <Mac-arena> May as well. CFM's here. 19:40:29: <Catfish_Man> ok. SoC it is 19:40:32: <Mac-arena> Although somebody said we should just do it on devl list at this point. 19:40:35: <Catfish_Man> we're getting pretty close to out of time 19:40:35: <Mac-arena> Do we want to do it on IRC? 19:40:46: <Catfish_Man> so I'm of the opinion that students should start wrapping things up 19:40:47: Mac-arena borrows the chairman hat from The_Tick since he's off eating dinner not at the computer 19:41:22: :Server: The_Tick has signed off (Read error: 104 (Connection reset by peer)) 19:41:56: <Mac-arena> Catfish_Man: Yeah? 19:42:00: <Catfish_Man> basically, unless anyone objects, I think we/I should email devl saying essentially 'finish whatever feature you're on, then cleanup & testing' 19:42:04: :Server: The_Tick (n=tick@growl/the-tick) joined #adium-devl 19:42:20: <Mac-arena> Or at least get status reports 19:42:20: hal2k has been in the cleanup&testing phase for a while now 19:42:27: <proton> sounds reasonable 19:42:42: <Mac-arena> "Do you have any features left to do? OK, you'll do these and these others that you don't have time for [if any] get cut" 19:42:51: <Mac-arena> (less brusquely, but you get the idea) 19:43:13: <Catfish_Man> we're 11 days out from "upload to google" on the timeline, 22 days from final eval 19:43:15: :Server: The_Tick_ (n=tick@adsl-70-142-154-90.dsl.hstntx.sbcglobal.net) joined #adium-devl 19:43:16: :Server: The_Tick has signed off (Connection reset by peer) 19:43:20: <Mac-arena> That close, huh? 19:43:32: <Catfish_Man> naturally I don't really care about the first of those, as long as it compiles ;) 19:43:40: <hal2k> Catfish_Man: do we really have to upload to google? 19:43:47: <Catfish_Man> hal2k: istr that was canceled 19:43:48: <Mac-arena> I thought they said no upload to Google. 19:43:51: <hal2k> Catfish_Man: I'm not sure how I could upload anything 19:43:56: <Catfish_Man> yeah, exactly 19:44:02: <Mac-arena> hal2k: Write a .url file with the svn: URL ;) 19:44:06: <hal2k> heh 19:44:29: <hal2k> afaik it's just a form durin42 is going to write up to fill out again 19:44:35: <hal2k> durin42: ping 19:45:04: <jas8522> could still be on the phone 19:45:13: <jas8522> this long... either his girlfriend or his mother :| 19:45:15: <hal2k> probably a woman on the other end 19:45:19: <jas8522> hahaha 19:45:24: <elliott> no doubt 19:45:34: <hal2k> :) 19:45:46: <edr1084> you mean his fiance 19:45:53: <Mac-arena> Fiance would be male. 19:45:57: <Mac-arena> Perhaps you know something we don't? 19:45:59: <edr1084> umm... 19:46:02: <jas8522> wtf 19:46:11: <edr1084> since when is that male? 19:46:13: <Catfish_Man> Mac-arena: getting back into pedant practice, I see 19:46:17: <Catfish_Man> fiancee is what you want 19:46:21: <Mac-arena> Fiance = who she's marrying. Fiancee = who he's marrying. 19:46:21: <jas8522> really? 19:46:27: <elliott> hahaha 19:46:28: <jas8522> I had no idea 19:46:28: <elliott> oh Mac-arena 19:46:33: <Mac-arena> Catfish_Man: Indeed ;D 19:46:38: <jas8522> :P 19:47:15: <Catfish_Man> mmmm " In a canvas test page, which I broke off from the Safari 19:47:15: <Catfish_Man> pageout test, I saw an RPRVT reduction of ~10MB." -- dave hyatt, in a commit log just now 19:47:22: <Mac-arena> Yum. 19:47:42: <Mac-arena> So anyway. GSoC Mentors: Get your students to wrap it up. And you'll be emailing the list with the same message, CFM? 19:47:49: <Catfish_Man> yup 19:48:14: <Catfish_Man> oh, and for those I haven't spoken to, I'm definitely interested in feedback on my contact controller email 19:48:27: <elliott> As an aside, do we have targets for 1.1, 1.2, and 1.3? 19:48:29: <proton> Catfish_Man: that was ggaren 19:48:40: <proton> reviewed by hyatt :) 19:48:40: <Catfish_Man> oh, so it was 19:48:49: <hal2k> Catfish_Man: no objections from me, I guess it's just the result of last year's discussion anyways :) 19:48:49: <Catfish_Man> I always see the reviewed-by first 19:49:01: <Mac-arena> elliott: A red bull's-eye for 1.2, a paper dummy for 1.2, and a clay pigeon for 1.3. 19:49:12: <elliott> hah 19:49:13: <Catfish_Man> Mac-arena: oh? two targets for 1.2? 19:49:17: <elliott> Do we have target dates? 19:49:19: <Mac-arena> s/1\.2/1.1/ 19:49:42: <Catfish_Man> tab length and swedish are the last two tickets on 1.1 19:49:46: <Mac-arena> elliott: Not on roadmap. 19:50:01: <Catfish_Man> I have a patch to PSMTabs ready that *may* fix my issues 19:50:20: <proton> Catfish_Man: re naming: I'd strongly suggest you don't use "AIContact" for anything 19:50:21: <Mac-arena> Ping The_Tick about it and enter it into the record for this meeting after he responds. 19:50:30: <Catfish_Man> proton: k 19:50:35: <proton> it's too ambiguous and is much harder to understand the code :) 19:50:43: <Mac-arena> proton: What's ambiguous about it? 19:50:51: <Catfish_Man> as opposed to AIListContact? 19:50:52: <Mac-arena> Aside from connotations from existing code 19:50:53: <hal2k> proton: btw, keep me updated on your project :) 19:51:40: <proton> because just reading "AIContact" in code will be hard to work out if you mean a contact the user sees or a contact from a service or any of a number of things that might be contacts 19:52:15: <proton> AIPerson for a meta contact sounds better 19:52:26: <proton> AIServiceContact for AIListContact perhaps 19:52:29: <Mac-arena> Risk with AIPerson: Assumption that it inherits from ABPerson. 19:52:34: <hal2k> proton: oh btw, how does you project differ from CK? 19:52:37: <Mac-arena> Not to mention the fact that they look very similar at a quick read. 19:52:46: <proton> yeah, AIPerson I'm not 100% happy on, but it's better than AIContact :) 19:52:53: <Mac-arena> I'm not convinced. 19:53:06: <proton> hal2k: well it's just a library, not a complete framework with daemon type thing 19:53:16: <proton> it could be built into something like that in the future possibly 19:53:21: <Catfish_Man> Mac-arena: what if we made it inherit from ABPerson? ;) 19:53:24: Catfish_Man runs 19:53:27: <Mac-arena> As long as we document what an AIContact is, and what an AIContactUsername (or whatever) is, I don't foresee a problem. 19:53:30: <Mac-arena> Catfish_Man: Run! RUN FAST! 19:53:59: <gbooker> proton: adopting fire's naming scheme? 19:54:01: <proton> AIMetaContact and AIServiceContact possibly? 19:54:11: <proton> gbooker: yeah, i liked it better :) 19:54:14: <Mac-arena> Eh. 19:54:16: <gbooker> so do I 19:54:19: <Mac-arena> Metacontact sounds weird. 19:54:22: <gbooker> no confusions on what things mean 19:54:28: <Mac-arena> Perhaps AIContactContainer? 19:54:33: <Catfish_Man> no 19:54:40: <Mac-arena> gbooker: What's Fire's naming scheme? 19:54:43: <Catfish_Man> because AIContainingObject is still around 19:54:57: <gbooker> a person is a collection of beddies 19:55:09: <gbooker> buddy is the service level "contact" 19:55:09: <Mac-arena> Catfish_Man: And an ex-AIMetaContact would still be an AIContainingObject, right? 19:55:14: <gbooker> and person is the meta-contact 19:55:17: <Catfish_Man> Mac-arena: indeed 19:55:18: <Mac-arena> Oh, I see. You expect that it would be confused with that protocol. 19:55:35: <Mac-arena> Such that people would expect groups to be AIContactContainers. 19:55:38: <Catfish_Man> AIContactContainer <AIContainingObject> is a little weird 19:55:41: <Mac-arena> That too. 19:56:15: <Mac-arena> AISomebodyElse and AISomebodyElsesUsername? ;) 19:56:51: <Mac-arena> (Of course, I'm on my own CL several times...) 19:57:26: <proton> anyway, the point is that "contact" is a very ambiguous term in an IM application 19:57:33: <proton> so using it as a class name is a bad idea :) 19:57:34: <Catfish_Man> Mac-arena: so AIMaybeSomebodyElse 19:57:41: <Mac-arena> Hehe 19:57:43: <Catfish_Man> haskell-style 19:57:48: <Mac-arena> AIContactMonad 19:58:06: <Mac-arena> (Note: I don't know Haskell nor begin to understand monads, so I may be making a wholly nonsensical joke there) 19:58:10: <Catfish_Man> heh 19:58:33: <Mac-arena> So, anyway, we can table that for next time/the list. Any other topics? 19:58:42: <Mac-arena> Catfish_Man: Happy with your virtual gerbil? 19:58:52: <elliott> ugh I hate NSDivideRect 19:58:52: <Catfish_Man> yeah, we just need to changelog it 19:59:01: <Mac-arena> Yeah. 19:59:08: <Mac-arena> Last call for other topics! 19:59:23: <Mac-arena> In the immortal words of Mitch Hedberg 19:59:26: <Mac-arena> Meeting ADJOURNED!
