oreilly.comSafari Books Online.Conferences.
Articles Radar Books  

You Have Mail!
Pages: 1, 2

Sending the Message

Once we've created the message, we can send it. It is worth looking at these two actions (create and send) separately, as it underlines the nature of what we're doing. I used the word "container" earlier to describe a Jabber message. What we've done here is to create a container, and its contents, and now we're going to send that container. But the sending of the container is not a method of the Net::Jabber::Message class -- it's a method of the Net::Jabber::Client class -- already instantiated in our script into the $connection scalar.

In other words, the message is just a parcel of data that is sent from our client to the Jabber server, thus:



Once we've sent the message, we're done, so we can use the Disconnect() method to close the connection to the server; this is essentially a wrapper around the Disconnect() method of the XML::Stream class, which is responsible for sending the proper closing XML tags to end the XML stream (the Jabber XML is sent in "stream" mode) and closing the socket.



OK. As an overview, here's the whole script, with comments, so you can see it all at once and understand how it fits together:

Related Articles:

The Jabber Jihad: Universal Instant Messaging With audio

Jabber Works: Here's How

XML Messaging with Jabber

Search O'Reilly Net for "jabber"

Instant Messaging topic area

More from the OpenP2P.com
# notify.pl
# Version 1
# E-mail notification script to Jabber client

use strict;
use Mail::Internet;
use Net::Jabber;

# Declare our constants
# ---------------------
use constant RECIPIENT => 'dj@yak';      # Jabber ID to be notified
use constant SERVER    => 'yak';         # Jabber server to connect to
use constant PORT      => 5222;          # Port to connect to
use constant USER      => 'notify';      # user this script connects as
use constant PASSWORD  => 'notify';      # password associated with USER
use constant RESOURCE  => 'perlscript';

# Read and parse email and extract header info
# --------------------------------------------
my $header = Mail::Internet->new(*STDIN)->head()->header_hashref();
chomp $header->{$_}[0] foreach keys(%{$header});

# Create a new Jabber client and connect
# --------------------------------------
my $connection = Net::Jabber::Client->new();
$connection->Connect( "hostname" => SERVER,
                      "port"     => PORT )
   or die "Cannot connect ($!)\n";

# Identify and authenticate with the server
# -----------------------------------------
my @result = $connection->AuthSend( "username" => USER,
                                    "password" => PASSWORD,
                                    "resource" => RESOURCE );
if ($result[0] ne "ok") {
  die "Ident/Auth with server failed: $result[0] - $result[1]\n";

# Create a message and build it up
# --------------------------------
my $msg = Net::Jabber::Message->new();
$msg->SetMessage( "to"      => RECIPIENT,
                  "subject" => "Email from $header->{From}[0]",
                  "body"    => join("\n", "Subject: $header->{Subject}[0]",
                                          "Date: $header->{Date}[0]") );
# Send the message
# ----------------

# Disconnect from the Jabber server
# ---------------------------------


Some Final Thoughts

Amazingly enough, it works -- here's a screenshot of a notification sent to me by the script:

A notification arrives

Figure 5: A notification arrives in my WinJab client

This is only an example, and as such has a lot of limitations. You might want to make the RECIPIENT value modifiable by, for example, using a command line switch so you could put something like the following into your procmail recipe:

:0 c
| ~/notify.pl -n qmacro@jabber.org

Also, the script is set to die if something goes wrong, so you're not necessarily going to find out very easily if something in the configuration (or with the Jabber server) is awry.

But by far the most interesting (and intentional) omission is this: What if the user to notify is not connected at the time the notification is sent? Or what if the user is connected but temporarily doesn't want to be disturbed by such notification messages?

If you're interested in knowing the answers to these questions, then you might find the next article, A More Sensitive Mail Notifier interesting.

DJ Adams is the author of O'Reilly's Programming Jabber book.

Discuss this article in the O'Reilly Network General Forum.

Return to OpenP2P.com.


P2P Weblogs

Richard Koman Richard Koman's Weblog
Supreme Court Decides Unanimously Against Grokster
Updating as we go. Supremes have ruled 9-0 in favor of the studios in MGM v Grokster. But does the decision have wider import? Is it a death knell for tech? It's starting to look like the answer is no. (Jun 27, 2005)

> More from O'Reilly Developer Weblogs

More Weblogs
FolderShare remote computer search: better privacy than Google Desktop? [Sid Steward]

Data Condoms: Solutions for Private, Remote Search Indexes [Sid Steward]

Behold! Google the darknet/p2p search engine! [Sid Steward]

Open Source & The Fallacy Of Composition [Spencer Critchley]