The ever annoying point-by-point reply from a 1.0 perspective of a programmer who's nevertheless not writing any code so far:
On 2010-01-25, at 17:24 , John C. Welch wrote: > > 1) Stop thinking about IMAP as if it were some cohesive standard with a > consistent implementation. Yes. Major suck. Yet you go on and on about supporting advanced IMAP features later. I think the way to deliver a consistent experience and eventually ship is to focus on the basics of IMAP, and do most things on the client. > 2) Regardless of who this project is aimed at, people using it are going to > get email from "icky" sources, like Outlook users who have no control over > their email format. ... Man, your real world sucks. TNEF eh. Can I say, plugin? I mean, we'd really love to support all kinds of shit other MUAs throw at us, but you know, programmers writing the code, programmers generally don't get TNEF email. Priorities and all. I'm sure that if a good implementation shows up, plugin or not, it'll ship by default. (There's some GPL shit to handle this, so a plugin could rely on it. It just wouldn't ship by default.) > 3) Implement IMAP well, or at least provide the option to behave properly. > (Mulberry is one of the few that do this). So when you have a list of > headers in a header view, that's all you download. I think we're going on that direction. > 4) Get copies of all the Mac IMAP clients and spend some time with them. We're doing the next, more viable thing, which is talking on this list and letting people share their whoas and woes with past clients. > 5) Cocoa is a design/programming methodology. It does not make the > application (not)suck. Since it's a Mac client, Cocoa is a given, and that's > really all the discussion it should have had. See, no discussion. > 6) License. Dear lord, just BSD it and be done with it. There's been a decree by the president. We don't talk about the RMS BDSM license anymore. > 7) AppleScript is a must. I agree—with a lot of pain—for the exact reasons you mention. I'm just personally staying away from it and doing everything on the shell. > 8) Some reaching out to Server vendors about what kind of hooks they > provide, if any, to server side email filters might be a good idea. As per point one, plugin territory. Likely too vendor specific. > 9) Please pay attention to auth options. +1 > 10) Everything can handle a correct message. Some attention to "how will > this handle mangled crap" is important. I, for one, would love to get my hands on a useful corpus of craptastic mail. > 11) "that can be a plugin" is a trap unless you design the plugin API first > or damned close. We're too far away from this in dev to have any concrete reply, but I hope the idea is to dog food the whole plugin system, implement as much of the application itself as plugins, not because it belongs in pluginland, but to ensure it can be done, to ensure it's reliable, and to stabilize the plugin API. > 12) It's a new application. Let the first version of the OS supports be > 10.6.X. No need to make testing suck more than you have to. There's been a decree of sorts by Gus. I'm not sure why the talk continued. > So now, as a NON-programmer email power user, (I'll put my load up against > anyone's), some things that aren't optional for an email client: > > 1) good rules. I don't mean the silliness you get in Mail. What I personally have in mind is something a lot more dynamic, that would take care of everything you mentioned by design, without a thousand tiny special cases. > 2) Mailing list handling. Again, Entourage has a solid option here. A much +1ed feature around here. *Wonders why* > 3) They have to be able to talk to the Address Book and iCal frameworks. It's part of being a Mac app. > 4) Three-pane has to be an option. It doesn't have to be the default, but it > has to be available. People are trained to expect that. I'd recommend > 'borrowing' E'rage's vertical take on the three-pane view as an option, if > you have a larger screen it's pretty tight. You mean mail-lame-3-pane? I've been pushing for NNW-widescreen, aka 3-column. The design effort on dev has gone that direction too. (I haven't fully caught up with the thread, maybe it diverged?) Again, I think 3-pane is a legacy of 4:3 screens. > 5) Categories with colors that are supported in the rules and scripting. Fair. > 6) Per-account reply options. My work account has to be top-post, everything > else I bottom post. Per any criteria, not just per account. Goes along with the "everything is search" thing that's being thrown around. > 7) HTML editor. Yes, I know text, blah, blah. Again, as the non-programmer Maybe. It'll not hold 1.0 back, that's for sure. If a patch comes along, and it doesn't suck. Maybe it'll make it. It's not my decision, and I'll withhold my opinion. I'll just say that I don't see anyone in the code department doing it. > 8) Quicklook. Yes. Please. Of course. > 9) Data Detectors ala Mail. They're verra nice. Also, for occasions when a > mangled URL isn't clickable, support for cmd-clicking doesn't suck. Been there, I think we love it. > 10) Plugins with a well-documented architecture, yes. Plugins with "here's > some source, that's all you need", no. The inevitable is we'll start with the latter to derive the former. As said earlier, implementing crucial application features as plugins should ensure we actually arrive there. > 11) Documentation. It's still important. Especially developer documentation, at this stage. Certainly end user later, as the idea is to offer an extensible client, and nothing sucks more than figuring out an alien system. A lot of people have volunteered. Let's hope they're still around by the time doc efforts can begin. > 12) It has to support sigs. In addition to the European requirements, Everybody wants sigs. I think they'll make it. > 1) Given the stupidity of mail retention rules, (don't get me started on > this), the ability to not use any local storage at all would be nice. Yeah I don't know about it. The original discussion about the backend implementation is that we'd cache everything. There's been a vocal minority that just wants everything on the server, nothing local. It may be doable because you inevitably have to talk to the server at some point, but I don't think it'll be truly optimized for. (I mean, basic headers first, messages later, attachments much later, yes. More than that, don't think so.) > 2) This is an actual IMAP thing, but rarely used: The ability to publish or > subscribe to folders, and the ability to unsubscribe to folders in your own > store you don't care about. Account-local un/subscriptions have been considered and I don't think they'd be much trouble to support. Although if the source list is customizable, why do you care what you're subscribed to or not? I guess there's some IMAP extension that lets you get notifications for all your subscriptions at once, instead of a single mailbox? That would justify giving it attention. As for publishing, totally 2.0. Can you make a good case for it? > 3) A good UI for server-side functionality, esp. searching. Actually, when > searching online folders, doing it on the server as the default when online > would not suck. Been there earlier. The consistent thing is to handle stuff on the client. Let plugins handle specific servers/server features. The kind of search we want to implement is beyond any server's capabilities. > 4) IDLE isn't just for inboxes Heard. > 5) MCX Manifests. (Yes, I want this to replace mail, the bane of my "oh, Sounds like something nice that I would never use. Hopefully can be handled by a 3rd party plugin. You evil IT needs are heard, but indies, you know, are indies for a reason. > 6) I could care less about external editors, and actually hate the concept. Then you don't use them. (And I wouldn't mind hard-coding against Word.) > 7) Power User != Programmer, Power User != Programmer, Power User != > Programmer, Power User != Programmer, Power User != Programmer, Power User > != Programmer, Power User != Programmer. There, point made. Yet, you'd be not surprised at all to hear that programmers are writing the code. Not evil programmers who hate the power user, mind you. But still, your point might not make all the way across. > 8) A scheduler that does more than just check for email. Another reason I I think this is inline with the programability/extensibility goals. > Did I mention I'm a verbose MF? Because I am. Welcome to the club. _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
