Okay, so some points here, (All at once, because that's what bandwidth is for!):
1) Stop thinking about IMAP as if it were some cohesive standard with a consistent implementation. It is not. It's a bloody mess that manages to work in spite of its implementations, and Google's IMAP implementation is one of the worst I've seen in the last 12 years I've been working with IMAP servers. As an example, here, supported feature lists by server: Gmail: IMAP4rev1, UNSELECT, IDLE, NAMESPACE QUOTA XLIST CHILDREN XYZZY Communigate Pro: IMAP4REV1 ACL NAMESPACE UIDPLUS IDEL LITERAL+QUOTA ID MULTIAPPEND LISTEXT CHILDREN BINARY LOGIN-REFERRALS STARTTTLS AUGH LOGIN PLAIN AUGH CRAM-MD5 AUTH DIGEST-MD5 .Mac: IMAP4REV1 MMP0743 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS CHILDREN BINARY UNSELECT SORT LANGUAGE IDEL XSENDER X-NETSCAPE XSERVERINGO X-SUN-SORT X-SUN-IMAP X-ANNOTATEMORE X-UNAUTHENTICATE XUM1 AUTH PLAIN STARTTTLS Kerio 6.7.3: IMAPREV1 IDLE ACL LITERAL+ UIDPLUS QUOTA ID SORT ANNOTATE ANNOTATE MORE STATUS-COUNTERS UNSELECT LISTEXT NAMESPACE XLIST X-KERIO STARTTTLS AUTH CRAM-MD5 AUTH PLAIN AUTH LOGIN AUTH DIGEST-MD5 So if anyone thinks they're going to just 'write to the standard' and be done with it, no, you're not. You're going to have to spend a lot of time with IMAP itself, which is not a very nice standard on a good day. There's no such thing as a standard IMAP implementation. 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. (You think I'm kidding about this. I'm not. You should see how bizarre an overly locked-down windows shop can be.) They won't have the option to get the sender to change format, so in addition to "normal" HTML, you should start thinking about building in TNEF decoding. In fact, if you do this well, it would be a monster point in the application's favor, since that's a major problem for people in the real world. 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. When you click on the message, you download the message contents. Attachments are not downloaded unless you want them to be via explicit action. Call it "IMAP Strict" if you like, but it's something that I've missed in almost every IMAP client I've used. It is ASTOUNDINGLY handy in low bandwidth situations, (HOTELS), albeit there's a bit of a lag. Various clients deal with this in different ways. Mail doesn't, E'rage lets you download the first n K of a message if you like, I forget about T-bird et al. 4) Get copies of all the Mac IMAP clients and spend some time with them. For example, I've seen a few features that already exist in Entourage, such as a dedicated Mailing List manager, "send then file" in the form of outgoing rules, etc. You don't want to repeat everyone's mistakes, but, seeing how other people have solved different problems is not a bad thing. 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. Namely, none. What you all *really* seem to mean is "Should this be an Objective C application ver. Some other language" and I think the obvious answer there is yes. It's a Mac app, ObjC has real advantages there, and I say this as someone utterly unimpressed with the 15 year rut computer programming has been forced into by the language wars. There are better things to care about. Having said that, language choice should be solely based on appropriateness to the task. Using this as a tech demo for <new exciting cool language> is completely wrong for an application that is going to be more than a programmer's toy. 6) License. Dear lord, just BSD it and be done with it. The GPL, especially at this point, almost REQUIRES Lawyers. Lawyers are not good for software, and BSD keeps them away. If someone wants to steal the code, no one here is stopping them. The ineffectual gun at ones head that the GPL provides will do no one any favors. 7) AppleScript is a must. That's not the ONLY way to automate things, and it shouldn't be here, but a well-done scripting implementation, (and for DEITY$'s sake, NOT APPLE'S! Mail/AB/iCal have the most craptacular scripting implementations ever. Mail's one good point is scriptable rules. Other than that, take a look at Entourage, it has a fantastic scripting implementation that you can do some pretty scary stuff with. (Or just plain evil. I wrote a script that converts messages in Entourage to structured PDF through Acrobat just to prove that Adobe was full of crap when they said you couldn't do this on a Mac. They were less than happy about it. Which of course, was the idea.) This application is not going to only interact with shell scripts and the handful of jstalk applications. It's going to have to work with a huge range of applications, and for that, you need AppleScript. (All arguments about syntax quality or lack thereof will be mocked for: Point, you missed it. As will "BUT WHAT ABOUT <OTHER> LANGUAGE!. Multiple languages are good.) If nothing else, it gives you a great way to see what the next version's new features should be. If a lot of people are scripting something, that's a hint. 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. If more than a few provide a way to set those up in the client, that could be a good target for initial plugins. (This kind of thing would be SMASHING for plugins) 9) Please pay attention to auth options. Kerberos is important here, along with all the rest. Also, make sure to use the keychain for certs. Don't reinvent that wheel, it really sucks when you have to manually install certs for multiple machines because the coders were too clever to use the keychain stores. 10) Everything can handle a correct message. Some attention to "how will this handle mangled crap" is important. Mail doesn't do too well here, and with e-mail, if it can't read that one message you need it to, regardless of who's at fault, the client fails. 11) "that can be a plugin" is a trap unless you design the plugin API first or damned close. 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. 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. Look at Entourage or Mulberry for some serious grownup rules. T-bird's not bad, but ignores the OS too much. On outgoing, there's one question: is it send-then-apply or apply-then-send. Both have things going for them. In my experience, people tend to assume the latter, (it trips people up with e'rage's outgoing rules all the time.) The rules should allow for multiple conditionals, with "unless any/all are met" along with "if any/all are met". Along with that, multiple actions should be allowed. By multiple, I mean *multiple*, not just 3-4. One thing that Eudora has that I've not seen much of is rules logging. An option for that would be excellent here. An explicit global "only apply rules to messages in the account Inbox" option is important too. That can bite you in the ass if you're not careful. Rules should be configurable via scripting, they should also (obviously) run scripts. 2) Mailing list handling. Again, Entourage has a solid option here. (What, you think I use that application because I'm a Microsoft fan? Please.) Among the better features: Automatic digest-bursting, (easier to implement with POP, but not impossible with IMAP), the ability to set an application default for always reply to list or to sender, the ability to NOT have other rules applied to mailing list messages. 3) They have to be able to talk to the Address Book and iCal frameworks. You don't have to add that functionality into the application, but one-click "add to ical"-type functions have to be there. (I don't even LIKE Address Book or iCal, but I recognize the need.) 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. 5) Categories with colors that are supported in the rules and scripting. They're really handy as a way to manage large quantities of email that wouldn't go together any other way, and exist outside of headers and message structure. 6) Per-account reply options. My work account has to be top-post, everything else I bottom post. 7) HTML editor. Yes, I know text, blah, blah. Again, as the non-programmer power user, HTML is a reality, and it needs to be properly managed. There's no reason to have the entire spec, but things like fonts, bold/italic/underline, alignment, real lists, and 'real' indents/tabs are not the work of satan. And that includes images. Welcome to the modern world, pretending it's not there helps no one. 8) Quicklook. Yes. Please. 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. 10) Plugins with a well-documented architecture, yes. Plugins with "here's some source, that's all you need", no. 11) Documentation. It's still important. 12) It has to support sigs. In addition to the European requirements, they're a business requirement for a lot of places. As far as sig stripping goes, well, if the client does it the correct way, then you have a consistent header. If they don't, well, there's little you can reliably do. Optional things, but they'd rule. 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. But that one can be a readily available plugin. (I have to live in that asinine world, I do NOT have to encourage nor like it) 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. It's an edge case even amongst IMAP wonks, but then again, isn't that who this application is for? 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. 4) IDLE isn't just for inboxes 5) MCX Manifests. (Yes, I want this to replace mail, the bane of my "oh, just rebuild the mailbox again" sysadmin existence. You put a proper MCX manifest in there, and there are a LOT of people who will use this thing.) 6) I could care less about external editors, and actually hate the concept. (Do YOU get gobs of email composed in Word? I do, and it sucks. It allll sucks. Bad idea. BAAAAAAD idea.) 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. 8) A scheduler that does more than just check for email. Another reason I stay with entourage are the reaper schedules I have for mailing lists. Lets me delete any mail over n days old in <folder list>. Really handy for stuff I don't care about keeping. Oh, and when it can run scripts, it's even cooler. That should work for now. Did I mention I'm a verbose MF? Because I am. -- John C. Welch Writer/Analyst Bynkii.com Mac and other opinions [email protected] _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
