On 2008-01-25 15:03:58 -0600, Jared Johnson wrote: > >One way to approach it could be to leave the current transaction > >object intact but add a method to say/query "do the recipients > >individually" and then have a method to access the individual ones. > >That way we can move plugins that need the extra information to use it > >and the ones that don't care to, uh, not. > > literally doing every recipient individually is suboptimal IMO. In our > case we have a very robust system of inheritance that some clients make > use of and some do not -- so when you send a message to 20 users at 3 > different hosted domains, you might wind up with 20 different sets of > expected behavior, or 10, or 3, or 1.
That's why I wrote cf_wrapper (it's in the contrib directory), which
checks the results for all recipients and returns a temporary error when
they don't agree - when the client resends the message, it can "split"
them into two groups with consistent responses. It an awful hack from
the protocol perspective but works quite well in practice. The API could
use some work though - it currently cannot transparently wrap other
plugins, the plugins have to be written for cf_wrapper.
hp
--
_ | Peter J. Holzer | It took a genius to create [TeX],
|_|_) | Sysadmin WSR | and it takes a genius to maintain it.
| | | [EMAIL PROTECTED] | That's not engineering, that's art.
__/ | http://www.hjp.at/ | -- David Kastrup in comp.text.tex
signature.asc
Description: Digital signature
