On Jan 25, 2010, at 2:24 PM, John C. Welch wrote: > > 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: <snip> > There's no such thing as a standard IMAP implementation.
Bleh. Well, that's irritating. I didn't realize the landscape was quite that fragmented... > 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. ++ TNEF is a royal pain. I have to wonder, though, if there's some serious hurdle preventing Thunderbird (for instance) from including a TNEF decoder by default--perhaps Microsoft has some sort of (*ick*) patent on it? > 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. The right language and API for writing a native Mac app is Objective-C/Cocoa. It is not a cool toy language, it is not going anywhere, and it is what code has, I think, already been started writing in. > 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. Err...most of your points I get (I don't always agree, but I get ;-) ), but this one seems a little incoherent to me. I will try and summarize what I think I understand from this, and hope you will confirm or correct (or complete): - You want robust and pervasive scripting support - You want it to support AppleScript - You want it to at least optionally support other languages - You want the scripts to be able to do amazing and powerful things > 6) Per-account reply options. My work account has to be top-post, everything > else I bottom post. I would go further and say per-folder. > 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. ++ > 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.) I don't think anyone's suggesting Word. BBEdit, yes. Word, no. > 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. But is the purpose of Letters to be an email client for "Power Users", or an email client for Programmers? Timothy Collett -- Yesterday it worked Today it is not working Windows is like that ~haiku~
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
