On 1/25/10 11:21 PM, "Jack Shedd" <[email protected]> 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. You can't have it both ways. If you say it's a mail client that uses IMAP, you're creating specific expectations about what that client does. > > 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. Then don't talk to IMAP. Talk to POP. That's an easy standard. If you're going to do IMAP, either do it right or don't do it at all. Half-assed is bullshit. > >> 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. Says who. You have absolutely no way to prove that, and no, the plural of anecdote is not data. > >> 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. Right. Of course. It's always so bloody simple to take an existing code base and just make whatever changes you want. Why a child could do it. Hell, I have two cats, they should have 1.0 done by Friday, that's how absolutely trivial this is. No one in the history of coding has ever found they've coded themselves into a corner and now had to make radical fundamental changes to get out of it. It's allll magically easy. Back in reality land, you can't just blindly write code and hope for the best. Well, you can if you want hacky crap. If you want to do something that will be flexible for the long term, and have a solid, stable code base that doesn't have to be shredded every version, you do this 'planning' thing you may have heard so much about. > >> 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. Oh yes. I forgot. Open source excuses all planning and logic. Just fling code at it. Eventually something will stick. It's just like making spaghetti. -- 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
