Re^2: RFC: Net::SMTP::Pipelining

Thank you for your comments!

It'd be even more interesting to me if the functionality was worked into Net::SMTP::TLS

One of the reason I chose this particular design (inheriting from Net::SMTP rather than using it within the module) is that I wanted to be able to mix it with other modules that also inherit from Net::SMTP (like Net::SMTP_auth and Net::SMTP::SSL). So version 0.0.2 will have a method ("extend_esmtp_pipelining" or somesuch) to which you can pass an object in a Net::SMTP (sub-)class which will then add the pipelining capability (I haven't actually thought about how to implement this 100% but I'm sure it can be done).

Unfortunately, this does not help Net::SMTP::TLS, because that module does not inherit from Net::SMTP, but rather reimplements it. So unless AWESTHOLM wants his module to depend on Net::SMTP::Pipelining (which I doubt he will want to do, the whole point of the existence of Net::SMTP::TLS seems to be the desire to be free of a dependency on Net::SMTP) there will have to be some porting involved I think. I'll be happy to do that porting if there are people who'd want such a thing (and your question shows there are :-), but I'd rather have the code living in it's own module for a few weeks at least, to see whether that shakes out any bugs. I also wish there'd be a way to avoid such porting (duplicate code bad), but having looked at Net::SMTP::TLS a little just now I don't think it could be avoided.

I'm sure others would like it worked into Net::SMTP since that's a commonly used module.

If that is indeed the case I'll be happy to do so. That was my initial plan when I first approached this problem, but I quickly found that the problem was sufficiently intricate, and the actual process of sending an email and reporting results sufficiently different, to have the code for it live in a separate module initially. Net::SMTP is in core (which has a reputation for disdaining new features) and I wouldn't want to plunk my (possibly buggy) code on millions of unsuspecting users. Releasing it as stand-alone seems the best way to beta-test. If there is indeed popular demand to having this feature in core I'll happily deprecate this module and move the code over.

All dogma is stupid.

Comment on Re^2: RFC: Net::SMTP::Pipelining Select or Download Code

Replies are listed 'Best First'.
Re^3: RFC: Net::SMTP::Pipelining by mr_mischief (Monsignor) on Feb 18, 2009 at 17:45 UTC
Inheriting from it is of course the next best thing. I probably should have mentioned that straightaway. People who want pipelining enough who are currently using Net::SMTP will no doubt be happy that only minor changes to their code are necessary. As a matter of fact, from a cursory inspection it seems it shouldn't take me much effort to clone what you have here and have it inherit from Net::SMTP::TLS instead. I'd like to take a crack at that sometime soon if I have your blessing to do so. Now that I think about it, having Net::SMTP::Pipelining and Net::SMTP::TLS::Pipelining (or should that be Net::SMTP::Pipelining::TLS?) wouldn't be such a bad idea. It is a great and useful feature, but it's not necessary for everyone. Keeping it out of the API of existing modules might be better in the long run. Now I'm torn.	[reply]
Re^4: RFC: Net::SMTP::Pipelining by tirwhan (Abbot) on Feb 18, 2009 at 19:54 UTC
I'd like to take a crack at that sometime soon if I have your blessing to do so. Absolutely, go for it. I still feel kinda queasy about the idea of duplicating code in two different modules. So maybe (thinking out loud here) it would be better to build a switch into Net::SMTP::Pipelining that makes it use Net::SMTP::TLS as the base class when it's called as Net::SMTP::TLS::Pipelining->new(). That would be messy internally but avoid duplication. And I'm not entirely sure that extending the incompatible API of Net::SMTP::TLS even further is the right way to go. It seems to me that a better way (in the long run) would be to create modules which add the extra functionality of Net::SMTP::TLS to a subclass of Net::SMTP (e.g. creating Net::SMTP_TLS and improving Net::SMTP_auth). Given that Net::SMTP::TLS does no longer seem to be very actively maintained, that way we could have all SMTP functionality that people want collected under one namespace and core module. But whatever rocks your boat :-). If you do create another module I'd call it Net::SMTP::TLS::Pipelining (not NS::Pipelining::TLS) though. NS::TLS is distinct from the other NS modules, so keeping stuff that's specific to it under it's namespace makes sense to me. All dogma is stupid.	[reply] [d/l]


XP is just a number
	PerlMonks