On 1/25/10 11:00 PM, "Thomas Worrall" <[email protected]> wrote:
> For example, you seem surprised that some of us don't know much about > IMAP: "Based on what I see about how people think IMAP works, I'm not > holding my breath on that part." Why are you surprised? Before I > joined this list I'd not really ever considered writing something that > used IMAP. Now, along with everyone else, we're in the phase where we > learn about this stuff, learn what's possible, and how it all works. > But I have a job that takes up most of my time, so I haven't spent the > last two weeks pouring over protocol specs. Given that this is a free > time project I'd expect to spend at least a couple of months learning. 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'. > > I guess what I'm trying to say is the feature set _is_ going to change > as we learn more about how this stuff works. There will be things that > people wrote off as unfeasible at first and actually aren't too bad, > and there will be others that seemed trivial and took too long. So any > list of features we agree on are bound to change as the project > progresses. Yes. But changes now are easier than changes later. > > On the specifics of your requests, there's a lot I agree with. I like > the idea of doing stuff with the bits of the IMAP protocol that no-one > knows exist. And I definitely agree with you that "make it a plugin" > is a cop-out. It's just how your requests are phrased that I'm taking > issue with. Feel free to champion your cause, to be sure, but don't > imply that we're out to con people about our target market or accuse > us of lying when we say that features will be considered over time. 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. Secondly, NOW is the time to decide what this thing is actually going to be. >From colors to button placement. Not 'let's write a bunch of code and see what we can fit in later'. That way lies madness. Or most open source user applications. Take your pick. 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. You can't pillage after you burn. -- 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
