> 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'.
Let's take this from the top. Fifty or so "enthusiasts" show up hat in hand on Brent's doorstep at the drop of a weblog post to try to define a good email client. They are encouraged to discuss wildly, and for some reason, not all of them know everything about IMAP. Some of them don't know the first thing about IMAP. But all of them are actually encouraged to fend for their features right now. It's a way of letting a thousand (feature) flowers bloom. Once this has gone on for long enough, consensus will eventually build for a series of features that we will need, and the plan will solidify. Through all of this, some people are going to need to write the code. A subset of the arm-flailing gaggle are already working on trying to build a good base architecture. Eventually, someone will need to understand a lot about IMAP. But it's not detrimental to the project that everyone a) outside of the implementation b) sing their part right now during early planning, c) regardless of documented experience, because we need to build a picture about what could be done, something that will then be tempered by actual implementation. It's brainstorming. We're not lead into the weeds because we need not follow, as manifest implementation plan, every single idea weathered right here. I would rather recommend against it. But I wouldn't recommend against aiming *towards* whatever application architecture will eventually arise. It may very well not be a process that produces immediate results, and if our first priority and single goal is simply to produce a well-behaved IMAP client, that would be something else. If you want to talk failed processes, there are mountains of skeletons after Apple Mail clones that got bogged down in the initial stages of development. The focus right now is to figure out how Letters is going to work as an application, to come up with a first estimate, and to then work towards implementation. So if you assume that not everyone who posts (even the ones with strong opinions) are going to be implementing the parts of the application that deal with the network layer, you will have less of a reason to worry. And please assume that ideas that are unimplementable or bad form will eventually be rooted out during the process. But in this phase of defining what could go in, doing the necessary, adequate work of finding out all the technical prerequisites and favorable conditions for every proposed feature is not only overkill, it's stifling the ability to get every idea on the table. We won't write our network layer tomorrow; even if we did, we won't finish it tomorrow. > 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. How fortunate that people have been appointed to have the authority to say "redo this". To go through all this work and not get something right and then *not make it right* would be a damn shame. But you also assume that we operate under regular premises. We don't operate under fairy dust premises, but we're willing to take every bit of extra effort to get it right - right down to the implementation. And as far as plugins go, I have accepted the logic that *if* you're going to allow plugins, then it's a huge net positive to make sure that core parts are built using that architecture because it keeps it honest. If you can only ever build mashed potato bookcases, it will fall by the wayside, but if it's routinely used, it will work and the architecture will be better for it. I'm not under the impression that Firefox is the best architecture in the world, but it's a pragmatic demonstration of this principle. Not everything in Firefox is labelled an extension, but most of it operates under the same auspices as they do. /Jesper _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
