On Thu, 12 Nov 2009, Greg A. Woods wrote: > At Thu, 12 Nov 2009 21:21:24 +0100, Xavier Bestel <xavier.bestel@xxxxxxx> wrote: > Subject: Re: Exec'ing a script from Cyrus when imapd has a client >> >> Do you gain anything if Cyrus doesn't >> fulfill the needs of some users ? > > Did I ever say Cyrus should or should not meet the needs of some users? > > I think you've got something backwards here. > > Why should any one "product" meet the needs of all users? That's the > "if all you've got is a hammer..." analogy. Cyrus IMAP will _NEVER_ > meet the needs of all users, and that's fundamentally what I've been > trying to say from the start. If you don't need it then don't try to > wedge it into your implementation! > > We all gain if we can avoid the "all you've got is a hammer" trap, and > indeed we all gain if we can help each other avoid that trap too. > > If I'm not too mistaken it seems most everyone who wanted to use an IMAP > server as a client-level tool (by employing the likes of fetchmail) were > clearly falling for the "I have this Cyrus IMAP Hammer and I want to use > it to manage all of my e-mail even though I'm not running a server" trap. > Certainly that seemed to me to be the OP's situation. > > The real fear I have is that as a result others will believe that this > kind of use is condoned and approved, or worse that these folks were > actually setting up such things for other groups of users. In both > cases we end up with naive users who will not understand the issues > involved. Issues such as mangled headers, unreliable delivery, loss of > e-mail, and so on. who are you to officially condone or approve any particular use? who on this list (or any list) has the authority to do so? it's fine to suggest other solutions, but if people then say that those solutions cannot be used in these cases (and especially when they give the reasons) continuing to argue that it's wrong and evil to use the tool that way is not productive. you may not choose that solution, but that may be because you have resources available to you that make a different solution better. > Sure, it's all fine and dandy for someone to want to learn about a > product like Cyrus IMAP (or even fetchmail) by installing and using it > in some form where they can personally make use of it. > > However if the goal is just to make something work in the real world for > end users then we really need to go back to the fundamental end-user > requirements and figure out how best to meet them without creating > hidden problems along the way simply because we've got this hammer in > our hands and we're dying to bang away on something. If the user wants > some screws installed then we'd be doing them a huge favour if we would > go and find the proper screwdriver to do the job for them! even if the OP was using UUCP for the mail transport, the question he asked (how to have a job run frequently when a user is logged in, and not run if there are no users logged in) is still a very useful question to get an answer to. you have focused on the fact that he wants to use fetchmail as the transport between the full-time internet and his intermittently connected network and are telling everyone that he absolutly, under no conditions should try to do what he's attempting. that's where we have severe disagreements. most of the rest of us see situations where the basic approach he's doing could be the best possible approach. we may quibble over exact details of some of the things (use fetchmail vs UUCP vs other), but that doesn't make the basic approach invalid. David Lang ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
