Quoting Robin Bankhead <ho...@headbank.co.uk>:
1. The "cleanest" way to attack this (least disruption to existing
core code) seems like it would be to make a child to the
Horde_Mail_Transport_Smtp class. Is that extra level of inheritance
likely to break anything else, that you know of?
No.
2. Would invoking by default this putative child class (call it
Horde_Mail_Transport_Smtpcustom) be simply a matter of declaring
$conf['mailer']['type'] = 'smtpcustom' ? The idea being I'd then
not need to alter IMP_Compose::sendMessage().
$conf['mailer']['type'] = 'Horde_Mail_Transport_Smtpcustom';
For factories, Core tries to load the driver by appending to the base
driver name and, if this fails, it tries to load the parameter as a
class name. Note that the latter implies that the extended class can
live anywhere, as long as it is autoloadable (i.e., you can store
local classes in a horde/config/lib directory).
To ensure a class is autoloadable, just directly include/require the
file at some point prior to the class being accessed.
3. In one scenario (mixed local and external recipients) I'd need to
effectively split the message into two when sending (one for each
category of recipients, going to their respective mailers). At
first blush it seems like I could do this within my Smtpcustom
class; do you agree, or would it
(a) be offensively improper conduct, and/or
(b) break things all over the place?
(I notice that IMP_Compose::buildAndSendMessage() is where this
splitting happens for S/MIME multi-recipient messages, so I could
probably do something there but it'd mean making my code additions
less self-contained.)
It depends on whether you want to accurately report via sent-mail what
the messages actually look like. If you don't care, this can be done
within the mail class. If you want to report to the user that
messages actually were sent in two different packages, you would need
to edit/extend the compose class.
Mail transports may/probably already "split" messages for purposes of
delivery, so I would think the former solution is perfectly acceptable.
michael
___________________________________
Michael Slusarz [slus...@horde.org]
--
imp mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: imp-unsubscr...@lists.horde.org
