Interface between external packages and DJabberd proper

[Artur Bergman]

You could write a plugin that provides this and subclass from it.

If it works out, we should include that in the standard distro.

Cheers
Artur

On Aug 4, 2008, at 4:36 AM, Bron Gondwana wrote:

> Hi Michael, All,
>
> I've just been hacking away on DJabberd::Plugin::PrivateStorage,
> making it asynchronous supporting.
>
> In the process, I realised there's an awful lot of "infrastructure
> coding" that goes into these plugins.  In particular I wound up
> registering a couple of hooks, calling said hooks, and of course
> there was Michael's original code which contained:
>
> ||     my $private_cb = sub {
> ||         my ($vh, $cb, $iq) = @_;
> ||         unless ($iq->isa("DJabberd::IQ")) {
> ||             $cb->decline;
> ||             return;
> ||         }
> ||         if(my $to = $iq->to_jid) {
> ||             unless ($vh->handles_jid($to)) {
> ||                 $cb->decline;
> ||                 return;
> ||             }
> ||         }
> ||         if ($iq->signature eq 'get-{jabber:iq:private}query') {
> ||             $self->_get_privatestorage($vh, $iq);
> ||             $cb->stop_chain;
> ||             return;
> ||         } elsif ($iq->signature eq 'set-{jabber:iq:private} 
> query') {
> ||             $self->_set_privatestorage($vh, $iq);
> ||             $cb->stop_chain;
> ||             return;
> ||         }
> ||         $cb->decline;
> ||     };
> ||     $vhost->register_hook("switch_incoming_client",$private_cb);
> ||     $vhost->register_hook("switch_incoming_server",$private_cb);
>
>
> I wonder how much of this "standards support" code should actually
> be pulled back into DJabberd rather than maintained by external
> packages.
>
> I can certainly see the point of having external modules for  
> supporting
> backends, but there's a really large API boundary being crossed
> here, and the plugins are having to understand a whole lot about the
> innards of DJabberd.  This not only constrains DJabberd from changing
> the interface to any component without breaking external packages, but
> it is a bit of a pain to learn just to develop a simple plugin.
>
> What do you guys think?   Should this sort of thing be pulled back  
> into
> DJabberd proper while there are only a few CPAN packages depending on
> knowledge of the internals.  There are, what, 200 XEPs or so?  If we
> stub these with hook calls then plugin authors can deal with just the
> information they need.
>
> (and it doesn't have to be done all at once - start by stubbing the  
> ones
> that plugins actually use, and bug the authors of said plugins to use
> the new hooks that give them what they need instead - the old way will
> still work, just there will be an extra empty hook called as well)
>
> Bron ( rocking the boat for fun and profit )