On Jan 25, 2010, at 8:21 PM, Jack Shedd wrote: > 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.
No, Letters was always going to be a great Mac IMAP client. It was proposed as a Cocoa IMAP client before it was even called Letters. The whole project came about because lots of people started using IMAP instead of POP because of the iPhone. Its an IMAP client, first and foremost. That means it needs to work, seamlessly, with as many IMAP servers as possible. In order to do this, maybe we should listen to people who administer IMAP servers. > >> 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. BWAHAHAHAHAHA! I'm sorry, but maybe large, complex software projects are different, but if I start an experiment in my lab without some serious preparation, shit don't work. This needs to be planned out. That's Gruber's job. > >> 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. 2.0 versions, which have a tendency to involve major rewrites? > >> 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. Again, that's why we have a benevolent dictator here. We're not trying to have a typical open source project. We're trying to create a great Mac app that just happens to be open source because that's the only way that it was going to happen. Letters is going to have a lot more Steve Jobs than Richard Stallman in it. Paul Ward [email protected] _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
