Mail::Sender allows you to log all conversation with the SMTP server into a file that will look somewhat like this:

>> 220 ooa Microsoft ESMTP MAIL Service, Version: 5.0.2195.5329 ready 
+at  Wed, 21 May 2003 14:11:18 -0600 
<< ehlo CZXXPRA01SV0007
>> 250-ooa Hello [xx.xx.xx.xx]
>> 250-AUTH GSSAPI NTLM LOGIN
>> 250-AUTH=LOGIN
...
>> 250 OK
<< mail from: <jenda@krynicky.cz>
>> 250 2.1.0 jenda@krynicky.cz....Sender OK
<< rcpt to: <jenda@krynicky.cz>
>> 550 5.7.1 Unable to relay for jenda@krynicky.cz

[download]
This is implemented by replacing the $sender->{socket} with a tied filehandle that reads or writes from/to the original socket and dumps everything read/written into a log file/another filehandle. Which means that the rest of the module doesn't have to care whether the debuging is on or off.

Currently the code implementing this resides within Mail/Sender.pm (package Mail::Sender::DBIO) and only supports print(), readline()/<>, CLOSE() and opened(). Do you think it would be worth to move it to a separate module and add support for other filehandle methods?

If so how should I name the module? And what other filehandle methods should it support?

Update: I guess I did not express this clearly :-) I'm not asking whether it would be more efficient to put the code into a separate file or something. I'm asking whether it would be worth to give the code a life (and name) of its own. Whether it would be worth to unattach the code from Mail::Sender, make it more general and let others use it in their modules.

Jenda
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
   -- Rick Osborne

Replies are listed 'Best First'.
Re: Should I extract Mail::Sender's debuging into a separate module?
by Ovid (Cardinal) on May 27, 2003 at 14:33 UTC

    Moving all of the debugging code into its own module makes plenty of sense. The code will only be compiled if needed, it would be easier to extend and there would be less clutter in the main body of code.

    As for what to name it, that really depends upon what you want it to do. Mail::Sender::Logging is a good name, but if you're going to extend the functionality, it might not be appropriate. If all you're going to do is log, though, you might want to check out Tie::FileHandle::Buffer. (It doesn't have proper test coverage though). If it works as advertised, it could greatly simplify your problem.

    As for the other methods to support: perhaps you could just make the module subclassable and allow other people to add their own methods as needed? That will take more work and more documentation, but it will make it more flexible.

    Cheers,
    Ovid

    New address of my CGI Course.
    Silence is Evil (feel free to copy and distribute widely - note copyright text)

[reply]

      Well the code is compiled only if needed. It's in a here-doc string that gets eval()ed if necessary.

      I could name it Mail::Sender::Logging or even just Mail::Sender::DBIO if I planed to use it only from Mail::Sender, but then I might just leave it inside Sender.pm. The real question is ... would someone else find this helpfull? I mean with a little trickery you might even be able to sneak such debuging to a module that has no debugging yet. You'd just have to extract the socket it contains somewhere inside and replace it with a handle tied to this class that would forward all reads/writes to the real socket: 

      use Some::Module;
use Socket::Logger; #or whatever name it ends up with

my $obj = Some::Module->new(parameters);

$obj->{_socket} = Socket::Logger->new($obj->{_socket}, $logfilepath);

... use the $obj

      [download]

      It's a good idea about the subclassability, thanks for that.

      Jenda
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
         -- Rick Osborne

      Edit by castaway: Closed small tag in signature

[reply]
[d/l]
Re: Should I extract Mail::Sender's debuging into a separate module?
by nite_man (Deacon) on May 27, 2003 at 16:02 UTC
    Hi Jenda,
    I'm working with your module. It's great work. I take off one's hat (joking apart).
    About your question, I'd like suggest to do a debug more compact. Because all data are written in thins log, including a content of attachment file. It makes the log file huge and it needs processing of debug data if I, for example, want to redirect this data into Apache log or log of my application.
    But, I think, that useful debug information is the information which consists only reply of mail server, without any attachments.
          
--------------------------------
SV* sv_bless(SV* sv, HV* stash);
[reply]

      Well I assumed the debug will only be used for debuging, instead of being logged in production. But I guess you are right, I should optionaly turn the logging off for the mail body&attachments to make the debug file smaller. I think the best solution would be to define four or five debug levels:

      • no logging
      • only conversation, not the mail data
      • conversation and mail message headers
      • conversation and mail message and part headers
      • all
      Thanks for your idea.

      Update: You may find a beta version with this implemented at http://jenda.krynicky.cz/Beta/Sender.pm let me know if this works the way you need. See the debug_level option.

      Jenda
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
         -- Rick Osborne

      Edit by castaway: Closed small tag in signature

[reply]
        I think, It's good idea to do several debug levels. I will try to use a beta version of your module.
        Thank you very much! 
              
--------------------------------
SV* sv_bless(SV* sv, HV* stash);
[reply]

Back to Meditations