On 1/25/10 5:00 PM, "Caio Chassot" <[email protected]> wrote:
>> Define "basics". That's really hard with IMAP. > > I'd start with "get email". Then you really don't' know much about how fun IMAP is as a spec. "Getting email" has multiple meanings on IMAP. > >>> 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.' If non-programmers don't count, then neither 1.0 nor 10.0 will really matter to anyone but the coders. > > >> 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. How long are old version supported. But it's nice to see that the real world problems with Plugins exist for someone but me, and that maybe they aren't magical. > > > 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. "you have the source, fix it yourself" is the ultimate Open source dodge, which is why it really only succeeds amongst programmers, or in the data center. > > >> 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. Since the end user will be the poor schlub who has to deal with plugin management, it should very much concern them. Ask photoshop users. >>> 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. If it's how someone gets work done, why should they change for you? What is objectively better about your way, better enough to switch years of muscle memory? Not different, but 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. > "Go away, you silly non-programmer" is what I'm hearing here. > > >>>> 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. If there's no documentation, it's 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. I find that pessimism tracks reality better than blind optimism. I live in the real world. It's a habit. >>>> 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. So will this actually have a feature at all beyond network connections as a 1.0? > > >>> 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? Maybe. Since you want to shove all server ops to some future version, the answer is probably "no". IMAP is not an easy protocol to do correctly, and this kind of thing is why. > > >> 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 Yeah. Stupid mainframes with deacde plus uptimes supporting tens of thousands of users with a single box. How stupid was THAT. > > 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. If you require full caching, you're saying "We only want indie devs and home users." > > 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. If you don't have a certain baseline, only you will use this. Which is what I'm hearing. "IF you couldn't write the code for letters, don't use it" > > >> 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. That's hard to believe since you want damned near every point I bring off shoved off to narnia. I'm sorry. Version 2. Forgive my cynicsm, but its pretty obvious to me. > > 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. And oddly, what determines 2.0? Why 1.0 users. So what happens when only indie programmers use the application? Well, they determine version 2. All those non-indie dev feature requests from pre-history? Oh, they didn't have any support post-release. Vicious, meet cycle. >> 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. Ah, elitism as a user requirement. Excellent. > > Not saying it's the case here. But it happens a lot. Oh, I see it happening here too -- 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
