Decision about server processing of stanzas

[Brad Fitzpatrick]

Artur was just touching this code, so I'll defer to him for now.
He might've even fixed it independently (he didn't know about this list
:/).

Can you write a test for this, now that we have such easy utility
functions for writing tests?  look at t/exchange-messages.t or t/vcard.t
to see how easy it is.  The two_parties function finds all sorts of fun
bugs, since it does both one-server and two-server cases.

As for the ->forward method, I agree that the process/forward switch code
is getting a little hairy, but I don't want to touch it quite yet as it's
not getting terribly annoying yet.  I want to focus on more tests, s2s bug
fixes (wildfire), ssl bugfixes (delayed write errors), cluster-wide
support, and more JEPs, notably MUC.  After that, performance work, and
cleanup along the way, using the growing test suite to give some
confidence that refactoring isn't hurting us too much.


On Tue, 2 May 2006, Pedro Melo wrote:

> Hi,
>
> I made a patch last night to fix IQ stanza processing. The problem is
> that a jid like node at domain where domain is one of your own domain is
> a server address to a IQ, but a client address to a message. So the
> uses_jid() method of DJabberd will think IQ's with that addresses are
> to the client.
>
> At first I modified the uses_jid() method to take that in account,
> but that messes up messages. So I hacked
> switch_incoming_client_builtin() in ClientIn instead.
>
> I don't like the shape switch_incoming_client_builtin() is taking,
> with lot's of isa()'s checks. The treatment of forwarding of stanzas
> is different depending on the type of stanza. My suggestion, and if
> you agree I'll code it that way, is that
> switch_incoming_client_builtin() just calls $stanza->forward(). Each
> stanza type then can decide if they should call process() or deliver().
>
> Anyway, first part of the patch, making sure IQ's to the server are
> not delivered to the clients, is attached.
>
> Best regards,
>