AnyEvent-XMPP

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    to file a bugreport to them, one hack less in AnyEvent::XMPP means more
    time for bug fixing and improvements and new features.

Why (yet) another XMPP module?
    The main outstanding feature of this module in comparison to the other
    XMPP (aka Jabber) modules out there is the support for AnyEvent.
    AnyEvent permits you to use this module together with other I/O event
    based programs and libraries (ie. Gtk2 or Event).

    The other modules could often only be integrated in those applications
    or libraries by using threads. I decided to write this module because I
    think CPAN lacks an event based XMPP module. Threads are unfortunately
    not an alternative in Perl at the moment due the limited threading
    functionality they provide and the global speed hit. I also think that a
    simple event based I/O framework might be a bit easier to handle than
    threads.

    Another thing was that I didn't like the APIs of the other modules. In
    AnyEvent::XMPP I try to provide low level modules for speaking XMPP as
    defined in RFC 3920 and RFC 3921 (see also AnyEvent::XMPP::Connection
    and AnyEvent::XMPP::IM::Connection). But I also try to provide a high

lib/AnyEvent/XMPP.pm  view on Meta::CPAN

fixing and improvements and new features.

=head1 Why (yet) another XMPP module?

The main outstanding feature of this module in comparison to the other XMPP
(aka Jabber) modules out there is the support for L<AnyEvent>. L<AnyEvent>
permits you to use this module together with other I/O event based programs and
libraries (ie. L<Gtk2> or L<Event>).

The other modules could often only be integrated in those applications or
libraries by using threads. I decided to write this module because I think CPAN
lacks an event based XMPP module. Threads are unfortunately not an alternative
in Perl at the moment due the limited threading functionality they provide and
the global speed hit. I also think that a simple event based I/O framework
might be a bit easier to handle than threads.

Another thing was that I didn't like the APIs of the other modules. In
L<AnyEvent::XMPP> I try to provide low level modules for speaking XMPP as defined
in RFC 3920 and RFC 3921 (see also L<AnyEvent::XMPP::Connection> and
L<AnyEvent::XMPP::IM::Connection>). But I also try to provide a high level API for
easier usage for instant messaging tasks and clients (eg. L<AnyEvent::XMPP::Client>).

lib/AnyEvent/XMPP/Client.pm  view on Meta::CPAN

If the account is not yet connected it will be connected on the next call to
C<update_connections> and if an account is connected that is not in
C<$accounts> it will be disconnected.

=cut

sub set_accounts {
   my ($self, $accounts) = @_;


   for my $accid (keys %{$self->{accounts}}) {
      my $acca = $self->{accounts}->{$accid};
      if (!grep { cmp_bare_jid ($acca->jid, $_) } keys %$accounts) {
         $self->remove_account ($accid, "removed from set");
      }
   }

   for my $acc_jid (keys %$accounts) {
      $self->add_account ($acc_jid, @{$accounts->{$acc_jid}});
   }
}

=head2 send_message ($msg, $dest_jid, $src, $type)

lib/AnyEvent/XMPP/Connection.pm  view on Meta::CPAN

=item stream_features => $node

This event is sent when a stream feature (<features>) tag is received. C<$node> is the
L<AnyEvent::XMPP::Node> object that represents the <features> tag.

=item stream_pre_authentication

This event is emitted after TLS/SSL was initiated (if enabled) and before any
authentication happened.

The return value of the first event callback that is called decides what happens next.
If it is true value the authentication continues. If it is undef or a false value
authentication is stopped and you need to call C<authentication> later.
value

This event is usually used when you want to do in-band registration,
see also L<AnyEvent::XMPP::Ext::Registration>.

=item stream_ready => $jid

This event is sent if the XML stream has been established (and