On 2010-01-25, at 19:25 , John C. Welch wrote: > >> Yes. Major suck. Yet you go on and on about supporting advanced IMAP features >> later. I think the way to deliver a consistent experience and eventually ship >> is to focus on the basics of IMAP, and do most things on the client. > > Define "basics". That's really hard with IMAP.
I'd start with "get email". >> Man, your real world sucks. TNEF eh. Can I say, plugin? > > I have that now. If that's the answer, Letters loses to inertia. You seem to have a lot of very particular needs that may not be all addressable in a 1.0 release. Maybe it'll not be the client for you. Maybe by 2.0 it will. But this is just hand-waving, until there's an actual implementation. > 1) Great. Now when it breaks, whose fault is it? The application? The > Plugin? Who has to fix it? That's a valid concern. I don't have a good answer, but I have a shitty pragmatic one: If new version breaks your plugin, stick with old version. As for who has to fix it? Is plugin core? Then core shouldn't ship with incompatibilities in the first place. Is plugin open? Then anyone. We can't act as plugin nanny/gatekeeper. Some of the value and suck of open source comes from the ensuing chaos around it. > 2) if everything is handled by plugins, well, we kind of have that now via > external applications. Why would anyone switch to letters if they have to > spend real time dinking around with this plugin vs. that plugin? Maybe this is a good space for commercial devs to tackle. Make a stable distribution of Letters cooked up with the right plugins and some proprietary customizations for a particular target user, and support it. We're using BSD/MIT, we love money, just like you. It's fair game. With that said, I think it'll be in our best interest to ship with a decent reasonable feature set. If they are internally implemented through the plugin API or not, that shouldn't concern the end user. > There's a real difference between someone who isn't writing code doing that > and the people who ARE writing code doing that. Very true. >> Again, I think 3-pane is a legacy of 4:3 screens. > > Um, it's not lame if you've been using it for over a decade. As well, three > column has limitations, and not all screens are wide. All current screens are either wide or big enough. That you've been using it for over a decade is exactly the point I made elsewhere that people want 3-pane just because it's familiar, not because it's better. I'm willing to go 3-column only in the name of shipping, but I don't call this shot. Your, and others, preference for 3-pane has been noted. Let the implementors decide now. >>> 10) Plugins with a well-documented architecture, yes. Plugins with "here's >>> some source, that's all you need", no. >> >> The inevitable is we'll start with the latter to derive the former. As said >> earlier, implementing crucial application features as plugins should ensure >> we >> actually arrive there. > > Bad idea. Letting documentation wait until "it's done, we'll do it later" > sucks. Or do you really like it when Apple documentation lags public > framework releases by large amounts of time. Documentation is not a one-off > thing, it actually takes real skill, regardless of what "Dilbert" wants us > to think. I know how this can go downhill very easily. It's important that we have a clear leader to ensure it doesn't, and guess what, we do. It's Gruber's call to say when 1.0 is good to go. I hope he'll not call it good until the plugin API is stable AND fully documented. Extensibility is a major project goal, we can't leave it half-done. >>> 11) Documentation. It's still important. >> >> Especially developer documentation, at this stage. Certainly end user later, >> as the idea is to offer an extensible client, and nothing sucks more than >> figuring out an alien system. A lot of people have volunteered. Let's hope >> they're still around by the time doc efforts can begin. > > Um...again, no, they kind of have to proceed together. Otherwise, it gets > dumped into the "Later" bin which always translates to "Not me man" I understand your reading the worst possible situation out of what I'm writing. It comes from experience. But: I don't say later as in when the software is done. I mean later as in, not just now, but as soon as there is any software at all. >>> 1) Given the stupidity of mail retention rules, (don't get me started on >>> this), the ability to not use any local storage at all would be nice. >> >> It may be doable because you inevitably have to talk to the server at some >> point, but I don't think it'll be truly optimized for. (I mean, basic headers >> first, messages later, attachments much later, yes. More than that, don't >> think so.) > > Do both. It widens your audience rather a lot. And it widens coding and testing effort. I'd say the manifested need for it on this list has been greater than I expected. So maybe it makes the feature set for 1.0. Or 1.5. >> Account-local un/subscriptions have been considered and I don't think they'd >> be much trouble to support. Although if the source list is customizable, why >> do you care what you're subscribed to or not? > > Because there's a difference between not seeing a folder and not talking to > it at all. True. So you say once you unsub it's like it never existed. You don't even see its contents in an "All Mail Ever" smart folder? > Server side searching and the like is not some random feature. It's rather > one of the core bits of IMAP, the idea being you offload things that can be > handled by the server onto the server. A relic of mainframe days. :P See, now, if we do cached-only, this point is moot. If we have to support cache-less operation, then server-side search becomes a major need, which means yet another thing to code and test and support. Every feature is like that, sooner than you think it sprouts another 5 features. That's why we're wary of saying we'll support anything. It's just another chance to get fucked and never ship. > Again, if the sole purpose of this application is to make Indie devs happy > and everyone else can funk off and write plugins, someone say so, and I'll > make sure that all my non-Indie dev compatriots ignore this project. If > Letters is going to be a programmer-only toy, then someone grow a pair and > state it clearly, or let's stop pretending that only programmers are power > users. The stated goal is "programmers and power users", people like you will help us shape what exactly that means. But: Shipping 1.0 involves cutting features that may leave a lot of people out. It sucks, but that's the reality of software, and that's why we have 2.0s. > External editors are not a core feature of an email client. Why not shovel > all that silliness to a plugin? It might as well happen. Who knows. But here's one argument for why we may end up having it: During development, it might be simpler to support external editors first, before we get to implement any sort of editor at all. > By that logic, all applications should be only for programmers and if you > can't program, don't use computers. Well, by observation only, you'll have to agree with me that the majority of really successful open source projects are for people who can program. Even if it just means hacking some perl put together an apache conf file. Not saying it's the case here. But it happens a lot. _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
