Interface between external packages and DJabberd proper

[Bron Gondwana]

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 )