On Jan 25, 2010, at 10:07 PM, John C. Welch wrote: > Because I've already seen how ignorance about how IMAP works is already > threatening to lead this thing off into the weeds. If you're going to write > an IMAP client, a deep understanding of IMAP is not optional or something > you can just 'pick up as needed'.
Perhaps we should stop saying this is an IMAP client then? What if the stated goal is just "a great email client that uses IMAP"? That would allow the group to pick those parts of the IMAP protocol that fit with it's agenda, without bending it's agenda to the clearly messy non-standard standard that is IMAP. As far as I can tell, Letters was started with the express goal of writing a better email client for OS X, not for being a reference implementation of a perfect IMAP client. > Yes. But changes now are easier than changes later. Not necessarily. To get started, the group just needs a rough outline of possible problem areas. It does not need to have an absolutely perfect specification document. The best products are built was you go. > Unlike a lot of people, I HAVE been involved in email clients of this size. > More than one. None of those, nor any software project in history gets > easier to add features in later than sooner. > > None. That's an absolute lie. It's always easier to add a feature once you have something working that it is to build something with every possible feature you have in mind. Architecture, and approach matter more than "features". If what you are saying is true, no one would ever release a 2.0 version of anything. > Now, while things are mutable is when these decisions have to be made, > because every line of code that gets written, even just in preliminary > testing, makes those decisions just a little bit harder, because *no one* > likes throwing away 'functional' code, even if it forces you into things you > didn't think you wanted to do. That hasn't really been my experience. I've watched huge swatches of code disappear from every software project I've ever been apart if, at any time, the code got in the way of what we wanted to do. Architecture decisions are harder to change, but not impossible, but Implementation decisions are things that can change week to week. Especially in an open-source project. _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
