|
| Session Start: Wed May 23 08:58:51 2001 |
| *** Now talking in #mozmail | 08:58 |
| <mpt> | Wow, some real live Mozilla programmers in #mozmail ... I never thought I'd live to see this | 09:32 |
| <DamonGallaty> | Greetings | 10:02 |
| <Gerv> | Hey :-) | 10:03 |
| <ducarroz> | bonjour |
| <BenB> | hi all | 10:05 |
| hi Damon! |
| <DamonGallaty> | Hi there |
| <BenB> | nice, that the meeting worked. | 10:06 |
| * DamonGallaty | wonders if Bob Lord will be here |
| <BenB> | me too, since he's the reason that we postponed the meeting till today. | 10:07 |
| he's logged is as lord, I just pinged him. | 10:08 |
| DamonGallaty: what are your questions / goals for the meeting? | 10:09 |
| <DamonGallaty> | I would like to get the architecture established for these mail plug-ins | 10:10 |
| Or at least started |
| I like the outline presented at http://www.mozilla.org/mailnews/compose_ send_plugin_arch_notes.html |
| So maybe if we start from there and delve into specifics? | 10:11 |
| <BenB> | would you do it by yourself, or would you rely on Netscape emgineers to do that? |
| <DamonGallaty> | The architecture for all mail crypto plug-ins? I would rather not do that myself, but I will if I have to |
| I'd much rather have the more experienced mozilla folks designing it, because I don't know Mozilla as well as most of you | 10:12 |
| I'm happy to give my input, though |
| <BenB> | the problem is: if you ask Netscape to do that, I expect it to happen in 2002 :) |
| desgining is one thing, implementing another. | 10:13 |
| <DamonGallaty> | True enough. I guess what I mean is that it should at least be a group effort among interested parties |
| <Gerv> | Damon: I assume your long-term goal is to get PGP support in Mozilla 1.0 and the associated Netscape, either by default or easily-installable? |
| <DamonGallaty> | Absolutely |
| | *** mpt changes topic to 'PGP support in Mozilla' |
| <BenB> | DamonGallaty: netscape is extremely time-constrained. | 10:14 |
| <DamonGallaty> | Understood |
| If we can get a concrete design going, then I can at least do some of the implementation |
| <BenB> | DamonGallaty: so, any part that Netscape would have to do would probably slow everything down. |
| <ducarroz> | I have to disagree, now that we have an entreprise group, think like that should go faster |
| <Gerv> | So we have a tension here. Mozilla.org wishes this to be implemented in a clean, architecturally sound and extensible way. |
| PGP, Inc. wishes to have something concrete at 1.0. |
| <ducarroz> | the proof is LDAP support! |
| <BenB> | ducarroz: that would of course be very good |
| | *** mpt sets mode: +oo ducarroz Gerv | 10:15 |
| <sspitzerMsgMe> | ideally, we'd like to come up with a plan that leaves the door open for PGP / SMP |
| er, S/MIME |
| | *** mpt sets mode: +o sspitzerMsgMe |
| *** mpt has left #mozmail |
| <BenB> | I don't know, what the mozilla.org oppinion is. <Gerv> So we have a tension here. Mozilla.org wishes this to be implemented in a clean, architecturally sound and extensible way. | 10:16 |
| <DamonGallaty> | Yes...although I am specifically interested in support for PGP, this design should be broad enough for any mail crypto plug-in |
| <BenB> | Gerv: assuming Seth doesn't count as mozilla.org |
| <sspitzerMsgMe> | I count as mozilla.org |
| <Gerv> | BenB: I was guessing, but it's an educated guess. |
| I mean, mozilla.org wants quality code, right? |
| All over the tree. | 10:17 |
| <BenB> | Gerv: actually, 92 votes tells me: "Get this in!" |
| Gerv: no |
| <sspitzerMsgMe> | before we get too off topic, what's the agenda for this meeting? |
| <BenB> | Gerv: mozilla..org policy: "First working implementation goes in." |
| <sspitzerMsgMe> | what do we want to cover? |
| <Gerv> | BenB: It is? |
| * Gerv | shuts up |
| <sspitzerMsgMe> | BenB, you called this meeting, what's the agenda? | 10:18 |
| <ducarroz> | let's go back to the architecture issue please :-) |
| <BenB> | sspitzerMsgMe: what DamonGallaty wants it to be :) |
| sspitzerMsgMe: my questions are what I mailed already. | 10:19 |
| sspitzerMsgMe: first one being: |
| sspitzerMsgMe: what speaks against checkin in the current version right now, let people use it and improve it while it's in the tree? |
| sspitzerMsgMe: this is the most-wanted bug in all of mozilla. | 10:20 |
| hi ddrinan |
| <sspitzerMsgMe> | first, most wanted bug? you can't go by votes. |
| <ddrinan> | Hi! |
| <Gerv> | sspitzer: Why not? That's what they are _for_. |
| <sspitzerMsgMe> | for example, a crasher bug. that's got no votes, but it highly desired. | 10:21 |
| <BenB> | sspitzerMsgMe: ok, the most voted for bug |
| <Gerv> | And it's just under double the votes of the nearest competitor. |
| People are saying something here. |
| <sspitzerMsgMe> | crashers / dataloss, they come second to a bug with 92 votes? | 10:22 |
| not in my book. |
| <BenB> | sspitzerMsgMe: i agree, but we don't have a tradeoff here |
| <sspitzerMsgMe> | that's just an example of why votes don't decide what I work on. votes do have value, yes. |
| <BenB> | sspitzerMsgMe: checking it in as is costs no or almost no time. |
| <Gerv> | Also, if we fixed crashes before doing any feature work at all, we'd never do any feature work, given that Mozilla will never be crash-free. | 10:23 |
| <sspitzerMsgMe> | back to the question: the current version is not in an acceptable state. |
| <BenB> | sspitzerMsgMe: why, concretely. | 10:24 |
| <sspitzerMsgMe> | my reasons are listed in the bug report, and in n.p.m.mail-news |
| <BenB> | sspitzerMsgMe: say, damon wants a first version to go in ASAP. what would he have to do. |
| * BenB | tires to find them to discuss them one by one. | 10:25 |
| <sspitzerMsgMe> | I'd start by extending the mime and compose backend to be extensible in a dynamic way. | 10:26 |
| then, do the same for the UI, using overlays. |
| <BenB> | uh, i don't think that should be required to get it in. |
| sspitzerMsgMe: the code does use overlays |
| sspitzerMsgMe: extending composer and mime to be extensible is not something that can be done in reasonable time. | 10:27 |
| <sspitzerMsgMe> | well, then PGP isn't going to land in a reasonable amount of time. |
| <BenB> | sspitzerMsgMe: and hardly by an external, occasional contributor |
| sspitzerMsgMe: why not? |
| sspitzerMsgMe: why can't we use some rpomitive hooks for now |
| <sspitzerMsgMe> | because, the mozilla modules owners for that code aren't going to take the wrong design. |
| <BenB> | sspitzerMsgMe: consider that S/MIME is/was hooked up by MACROS (!) |
| sspitzerMsgMe: i think, you use 2 keasures here. | 10:28 |
| sspitzerMsgMe: why? |
| <sspitzerMsgMe> | there is no S/MIME support in mozilla. |
| <BenB> | sspitzerMsgMe: the hooks are there, or at least they were |
| sspitzerMsgMe: IÄVe seen them in libmime. |
| <sspitzerMsgMe> | you might be seeing some crust from the 4.x code base, but that's crust that doesn't work. |
| getting back to constructive direction, | 10:29 |
| <BenB> | sspitzerMsgMe: yeah, but the crust is there, and nobody bothers, even *though* it fulfills no purpose |
| <ducarroz> | right, they are old stuff from 4.x that probably don't work anymore under Mozilla |
| <sspitzerMsgMe> | Damon, I'd start with the arch notes. |
| <Gerv> | On an architecture point, I remember sspitzer saying that ROT-13 could be implemented using the new architecture. Will the new system support processing a selection, or part of a message? Because ROT-13 needs that. |
| <BenB> | Gerv: ROT-13 was just an example, since we lacked the real PGP plugin | 10:30 |
| <Gerv> | BenB: I am referring to sspitzer's given reasoning for asking me not to complete my JS ROT-13 implementation. | 10:31 |
| <BenB> | ah |
| <Gerv> | sspitzer, ducarroz: If we need to extend composer and libmime in the way that you say, is any Netscape resource going to be available to help Damon out? If so, when might it come available? |
| <sspitzerMsgMe> | PGP isn't a top priority for the mozilla mailnews team right now. (look at our bug lists, they're hard to argue with) | 10:33 |
| so I can't promise you any time |
| (at least from me) |
| but I can help Damon with the design |
| and answer questions. |
| <Gerv> | BenB: I take it your plate is also full? | 10:34 |
| <sspitzerMsgMe> | That seems like a fair model: Damon (and others) want PGP support, we can help them do the right thing. |
| <BenB> | Gerv: i have no intention to help with the implementation. |
| <Gerv> | sspitzerMsgMe: How about this for a deal? You and the mail/news team sit down and bash out some serious architecture design and implementation notes. ... |
| <BenB> | Gerv: i might test and I might be able to answer a few easy libmime questions. |
| <Gerv> | This way, Damon knows exactly what to do, and can get on with it with mimimum trouble. | 10:35 |
| <BenB> | or general mozilla questions |
| <Gerv> | It's also likely to be What You Want(TM). |
| <BenB> | DamonGallaty: feel free to contact me for them. |
| <DamonGallaty> | BenB: Will do |
| <sspitzerMsgMe> | we've started that, see the doc on mozilla.org. I haven't had the time to revise the document and flush it out, but it's a place to start. |
| it will require some investigation / prototyping. | 10:36 |
| but I'm not the only one who can do that work. |
| <Gerv> | sspitzer: No disrespect to your doc, but anyone who starts implementing anything on the basis of just that would be nuts ;-) |
| <BenB> | sspitzerMsgMe: as i said, i hardly understand what you mean. i assume damon has the same prblems. |
| <Gerv> | sspitzer: So, what you are really saying is that, not only does the work have to be done by someone, but someone who understands the code has to work out _how_ to do it? |
| <sspitzerMsgMe> | BenB: fair enough. I've been slow to respond (working on 0.9.1 stuff) |
| <Gerv> | (And, furthermore, there are no such someones around?) |
| <DamonGallaty> | The doc is a good outline, but I am not familiar with the specifics |
| Like streams and converters and such | 10:37 |
| <Gerv> | You are giving the man a pretty big hill to climb. |
| <sspitzerMsgMe> | Gerv: yes, if you want to add this type of feature, you are going to have to dive into the code base. |
| <BenB> | sspitzerMsgMe: damon did do that already. |
| <sspitzerMsgMe> | Damon: right. I have to learn more about that part of mozilla, too. |
| <Gerv> | sspitzer: As Damon has proved, it can be _added_ . |
| What you mean is "added in a generic and extensible way." |
| <sspitzerMsgMe> | Damon: that's part of the reason why the docs aren't as complete as they could be. I don | 10:38 |
| haven't had the time to investigate fully. |
| <Gerv> | Damon: Is there any chance of more resource from PGPI? |
| <BenB> | sspitzerMsgMe: please don't get me wrong, but |
| <sspitzerMsgMe> | if we do it right, users who don't wont PGP won't have to pay for it (with bloat or UI) |
| <BenB> | sspitzerMsgMe: you say "we cannot accept it as is, but we don't have time to tell you want we want either" | 10:39 |
| <sspitzerMsgMe> | and it will leave the door open for other models, like S/MIME, etc. |
| <BenB> | sspitzerMsgMe: you basically make it impossible for damon to get the feature in in a reasaoble time (say, 0.9.2) |
| sspitzerMsgMe: and I don't think that is right. |
| <sspitzerMsgMe> | this is a non-trivial feature. I have no estimate as to how long it will take. | 10:40 |
| <BenB> | as for bload for non-users: |
| <DamonGallaty> | Gerv: Unfortunately, no. Our dev resources are spread thin at PGP, Inc. as well |
| <BenB> | we have logts of features that only a small percentage of users use or that is only useful for netscape. |
| <DamonGallaty> | Gerv: And to make matters worse, this isn't the only project I'm working on. |
| <Gerv> | BenB: Aiming for 0.9.2 would not be realistic in any case, IMO. |
| <sspitzerMsgMe> | I've given you a place to start, I've been slow to respond to your questions and elaborate on the document. if damon is the only one working on this, I'd like to know how damon feels blocked. |
| <Gerv> | My worry is that, given the current situation and the requirements that damon has to meet, 1.0 is looking unlikely as well. | 10:41 |
| <BenB> | Gerv: given that it works already and that damon is resposnive, i think 0.9.2 is realistic, assuming no hurdles cropple up. |
| <sspitzerMsgMe> | Damon, what's blocking you? |
| <DamonGallaty> | sspitzer: I'm blocked by the fact that I apparently need to design and/or implement an architecture for mail crypto plug-ins | 10:42 |
| sspitzer: Which is a bigger task than I had originally set out to do |
| sspitzer: I suppose I'm not really blocked, but more like "extremely slowed down" | 10:43 |
| As has already been mentioned, it's doubtful that PGP will appear in 1.0 if I have to do this all myself |
| <Gerv> | Can we not reach a compromise, of the following form? If the architectural improvements are not going to get done by Netscape or PGPI resource before 1.0, then they aren't going to get done at all. Therefore, why can we not check in a version of Damon's current code which is refactored to minimise the impact on the current codebase (and we'll use overlays for the UI) and then rip it out once we do it better, later? | 10:44 |
| <BenB> | Gerv: yes, that's exactly what I aimed at in the beginning. |
| as a concrete suggestion: | 10:45 |
| <sspitzerMsgMe> | because we (the mozilla mailnews team) don't accept the patch. if you want to slap it into beonex, or on a branch, go ahead. |
| <BenB> | for the UI, we use overlays (damon says, this is done already) |
| for libmime, we use the current solution: the plugin, if installed, registers a new "content handler" | 10:46 |
| for text/plain and deregisters itself, if no PGP mail is found. |
| <Gerv> | sspitzer: So, you are saying the only way to get ROT-13 in Mozilla is to rearchitect composer and libmime to be extensible? Given that you refused my JS implementation, I assume this is what you are saying. | 10:47 |
| <BenB> | so, we have no impact for UI and libmime, if the plugin is not installed. |
| <Gerv> | Words fail me. |
| <BenB> | composer: |
| we add a call to an XPCOM component function that fails without error, if the component is not registered. | 10:48 |
| that would be a mimimal impact on non-PGP-users and would be a fair tradeoff, consideriung that composer doesn't support any plugins (which is its own fualt IMO) |
| sspitzerMsgMe: would that be acceptable? if not: why not? | 10:49 |
| <sspitzerMsgMe> | can you write up that architecture, so I can look at it when I have time? it doesn't sound like the patch that I saw. | 10:50 |
| <BenB> | sspitzerMsgMe: "write up that architecture"? | 10:51 |
| <sspitzerMsgMe> | gerv: about ROT-13, there are many ways to add rot-13 into mozilla. ideally, it would have been our proof-of-concept for mime / compose plugins. |
| <BenB> | as for UI and libmime, that's what I read in teh bug and in Damons mails > it doesn't sound like the patch that I saw. |
| DamonGallaty: can you confirm that the current patch works as I described, for libmime and UI? | 10:52 |
| <DamonGallaty> | BenB: Yes, it should work as described for sending |
| <sspitzerMsgMe> | (heads up, I've got to head out at 11 am). |
| Damon: and receiving? |
| <Gerv> | Gotta go. | 10:53 |
| --> runs off. |
| <BenB> | DamonGallaty: ? libmime is for recieving |
| Gerv: cu |
| <DamonGallaty> | Doh! Sorry got mixed up |
| Ok...yes, it working this way for receiving (libmime) |
| For sending, the plug-in is not XPCOM yet, but can be made so with minimal effort | 10:54 |
| <BenB> | sspitzerMsgMe: so, what exactly do you need to know? |
| about my proposal |
| <DamonGallaty> | The other thing to note is that the PGP overlay is not added dynamically to the composer UI at the moment | 10:55 |
| I have to research how to do that |
| <sspitzerMsgMe> | Damon: since that work won't be wasted no matter how we proceed, start there. | 10:57 |
| <BenB> | DamonGallaty: i don't understand. i thought, the point of overlays were to add them dynamically? |
| <sspitzerMsgMe> | BenB / Damon: can you come up with some notes on how and where you plan to hook into mime / compose? |
| that will buy me some time to respond to benb's emails and extend the document on mozilla.org | 10:58 |
| <BenB> | sspitzerMsgMe: you mean concretekly, with pseudo.code? |
| sspitzerMsgMe: since I reallyl don't know how to describe it more detailed. |
| <sspitzerMsgMe> | some general architecture notes, I'll post them on mozilla.org once you have them. | 10:59 |
| there are more people than just us who can comment on the design. |
| <BenB> | sspitzerMsgMe: so, basically what I just said, just more polished for a webpage? | 11:00 |
| <sspitzerMsgMe> | I've hit my time limit. Sounds like damon can work on some of the compose UI (moving to overlays), I can work on answering benb's questions and finishing up the document on mozilla.org, and benb can write up damon's current architecture. |
| the goal is to come up with something that will work for PGP and S/MIME (and our proof of concept, ROT-13) | 11:02 |
| <DamonGallaty> | I'll write up what the patch is ultimately supposed to do, in the direction it's going now | 11:03 |
| <sspitzerMsgMe> | Damon: great, send it to me and I'll put it on mozilla.org |
| <DamonGallaty> | Meaning without the "grand architecture" that is wanted eventually |
| <sspitzerMsgMe> | Damon: right. | 11:04 |
| I'm off. I'll continue to log #mozmail and put it on mozilla.org when the PGP discussion dies down. |
| | *** sspitzerMsgMe is now known as sspitzerAway | 11:05 |
| <DamonGallaty> | Well, is there anything else to discuss at this point? |
| <BenB> | DamonGallaty: only, if you have questions to me or ducarroz. | 11:06 |
| DamonGallaty: out of curioosity: when will PGP erlease the plugin on the PGP side (if you're allowed to say)? |
| or, what is the schedule from NAI? | 11:07 |
| s/from/of/ |
| <DamonGallaty> | Whenever support in Mozilla is ready |
| Because our QA team has to be able to test the plug-in |
| <ducarroz> | if nobody have a question for me, I'll go back to my bug list :-) |
| <BenB> | DamonGallaty: would it be possible to release a previous version earlier? | 11:08 |
| DamonGallaty: that would give *us* the chance the test the Mozilla plugin (the code we are talking about) |
| <DamonGallaty> | Not sure. I might be able to convince management to allow the release of a public "pre-alpha", but that's not guaranteed |
| I'll check into it | 11:09 |
| <BenB> | yes, something like that I was thinking of. |
| also, did you document the interface to the dll you call from the mozilla plugin, so GPG has a chance to implement a compatible plugin? | 11:10 |
| <DamonGallaty> | I didn't yet, but I will | 11:11 |
| <BenB> | good, thanks. |
| ping me when you did, so I can forwadr it to the GnuPG folks. |
| <DamonGallaty> | I'll add it to the next patch when I attach it to the bug |
| <BenB> | the functions look fairly easy, but you know how it is - the subtelties are what hunts you then :) | 11:12 |
| ok, thanks. |
| <DamonGallaty> | Yep |
| I think that's it then, for now. I'll write up this plan and try to get the current patch fixed up as soon as I can. | 11:13 |
| <BenB> | that would be cool. | 11:14 |
| DamonGallaty: thanks for your good work. |
| <DamonGallaty> | Thank you for supporting me |
| <BenB> | you're welcome. | 11:15 |
| it's in my own interest, too :) |
| <DamonGallaty> | Signing off. If you need to ask anything, e-mail me: dgal@pgp.com | 11:17 |
| <ducarroz> | bye everybody |
| <BenB> | cu ducarroz | 11:18 |