Julian Mehnle wrote:
>
> Alessandro Vesely wrote:
> > Julian Mehnle wrote:
> > > pureperlfilter is the bootstrapping executable for Courier::Filter.
> > > C:F cleans up its socket when shutting down (e.g. when told to by
> > > courierfilter), but refuses to start if the socket it wants to create
> > > already exists.
> >
> > I see. It is different from Courier's libfilter: libfilter provides for
> > triggering 432 messages when filters are active but temporarily down.
> > Don't you want that functionality?
>
> Define "temporarily down".
Any operation that cannot be done safely while the filter is running. E.g.
the user is editing one filter's code, or related configuration files, and
editing a copy is not convenient in that particular case. Thus, the user
does `courierfilter stop'.
> Courier::Filter itself, as a filter module framework, is never temporarily
> down.
However, when even just one module is temporarily down, then the whole filtering
process cannot take place properly. (Hence there is no need of a function that
temporarily stops only a single filter or an individual module.)
> Individual modules however can return whatever status code they want, and
> automatically cause a temporary error ("432 Mail filters temporarily
> unavailable.")
> if they crash for a given message.
> > > I have been thinking about an intelligent way for C:F to detect during
> > > startup if an existing socket is stale (then it may just be
> > > overwritten during restart) or belongs to an already running instance
> > > of C:F. But I haven't invested enough time into this yet.
> >
> > Shouldn't that be courierfilter's job?
>
> What do you mean? As far as I can see, socket creation and clean-up is the
> responsibility of individual courierfilters, and Courier's `courierfilter`
> executable does nothing to that extent.
That's correct. However, starting all filters is its responsibility.
If, at a certain time, courierfilter wants to start C:F and C:F has an already
running instance, then either courierfilter or C:F is in error. What I mean
is that C:F could just do what it has been told to do. Ben didn't report what
caused that error -btw, I answered for I thought you were out for the weekend.
In general, let's say the error may happen because of a wrong installation, or
a bug in courierfilter or in C:F. Event if it were a bug in the filter'code, it
would have be the old instance's fault, not the new one's. Hence the new
instance
can just install itself. Sanity checks are always wellcome, of course, and a
program may refuse to run when they fail. The point is just that, IMHO, there
is no intelligent thing that a filter might/should do in that case.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
