Exec'ing a script from Cyrus when imapd has a client

[David Lang]

On Thu, 12 Nov 2009, Greg A. Woods wrote:

> At Thu, 12 Nov 2009 21:21:24 +0100, Xavier Bestel <xavier.bestel at free.fr> 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