Clear questions and runnable code
get the best and fastest answer
Extending MIME::Liteby demerphq (Chancellor)
|on Sep 27, 2003 at 11:44 UTC||Need Help??|
Recently trs80 contacted me with a patch for MIME::Lite so that it would handle SMTP servers that require authentication in an integrated way. His initial patch (which he himself called not-production-ready) involved adding two properties to the internal object (auth_user and auth_pwd), two methods for manipulating these properties and the required code to begin the SMTP transaction with the required autheticaion call to the underlying SMTP object and server. My response was positive. Adding this can only make MIME::Lite more powerful and useful and as such is A Very Good Thing.
The problem for me is that I do not want to add methods and properties for this. MIME::Lite is a generic tool for generating MIME encoded emails. It need not send via SMTP, as it currently supports at least three transport mechanisms, and in fact is often not even used for the actual transport at all. Furthermore there is already a defined mechanism for setting transport options at a class level so that any MIME::Lite objects created will use the preconfigured options. The proposed changes don't play well with that angle as they require properties to be stored in the object itself, which to an extent precludes the existings transport configuration framework.
My next problem is that I am not the hugest fan of the transport configuration as it is. :-) Were I to be writing the send_by_smtp option brand new, I would not make it pass its arguments directly through to Net::SMTP, instead I would create my own arguments (closely modeled on Net::SMTP) so that this was more flexiblity for extension. But alas, unless I want to rewrite the entire module as a backwards compatibilty interface to a new cleaner interface (which actually isnt that bad an idea, beyond my having insufficient time to do it), I am constrained in what I can do.
So what im thinking is to create an extensible interface for handling things like this in a generic way. I proposed to trs80 that instead of creating two new methods we simply provide for a means to use the current configuration interface to do the same. My thought for doing this was to allow the send() method to take a hashref of "special options". These special options would easily be detectable in send_by_XXXX and either ignored or acted upon as was relevent.
To me this would provide an extensibilty pathway for transport options going forward. It would also alow me to provide a cleaner way of specifying options to Net::SMTP (I want to be able to turn SMTP debugging on without having to know what SMTP server I am talking to, and without having to pass undef as the server name, mostly because I think its confusing for beginners and also because that undef looks ugly.)
So the rub of the matter is what issues do you see with having to say
Would this be confusing? Do you see a better way? Thoughts are welcome... And im expecting trs80 to share his thoughts as soon as he gets the time.
Thanks for your time and thoughts,
First they ignore you, then they laugh at you, then they fight you, then you win.