Interface between external packages and DJabberd proper
Artur Bergman
sky at crucially.net
Mon Aug 4 16:58:30 UTC 2008
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 )
More information about the Djabberd
mailing list