Re: [Exim] local_scan() addition: views sought

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: Clive Goodhead
Data:  
Para: exim-users
Asunto: Re: [Exim] local_scan() addition: views sought

> I'm adding some requested features to the local_scan() API. One of

them
> is the ability to specify a message as part of the 250 SMTP

response
> when local_scan() accepts a message. The current interface has

only one
> string that local_scan() passes back: for failures this string is
> already used for the SMTP response, but for successes, it is used

to set
> $local_scan_data to pass on data with the message for use by

routers and
> transports.
>
> I don't really want to change the function's API by adding another
> string because this will make everybody's function stop working.
>
> The returned string may not contain any newlines for the success

case.
> At the moment, newlines in the string are forced to become spaces.

It
> occurs to me that I could use newline as a separator in this

string:
>
> All characters before the first newline are saved in

local_scan_data;
> All characters after the first newline (including any more

newlines)
> become part of the 250 response.
>
> This is still an incompatible change, but a smaller one.
>
> Views?
>


I believe strongly that making a change to the local_scan() API at
this
stage would not be a good idea because, as you state, existing
functions
would stop working.

As I have worked with local_scan() functions over the last couple of
months I have found them very powerful. I do not have a problem with
the solution that you propose but perhaps a more general solution
might
be better. For example, each line in the returned string could be
identified by a prefix (in the absence of a prefix the default for
message accepted could be to save the string in local_scan_data). As
the exim code is updated for new suggestions/requests new prefixes
could be defined; existing functions would still work but not use
the
new features.

I'm not sure how many uses of the returned string have been
requested
(personally I am happy as it is). If no other uses of the returned
string can be envisaged my suggestion would add an unneccessary
element
of complexity and should be ignored. If, however, we can foresee a
multi-line (3 plus) return string, I prefer the prefix method to
avoid
having to make sure that the necessary lines (perhaps including
blank
lines) are returned in the right format and order.

Clive Goodhead