Hi Justin!
Justin Karneges schrieb:
I don't have a strong preference really. A component feels a bit more
like a client because it is a local connection, plus c2s connections are
simpler than s2s connections. Let's pick one and be done with it. :)
The reason why I for the most part suggest using jabber:server instead
of jabber:client is, that in the jabber:client namespace the from
attribute on stanza is optional, while on jabber:server it is not. I
think this is one of the biggest differences between these two
namespaces.
In fact I think it's the only difference. ;-)
There's an even bigger one: server connections can only send stanzas in one
direction. Although that's more of a protocol thing than a schema thing, if
you want to get picky. :)
That's exactly what I thought. You will probably implement s2s and
component connections in different components, so that the protocol part
is not that important. - But the schema is shared between both if they
use the same namespace. That's why I would pick the jabber:server namespace.
BTW: Even jabber:server connections do not have to be unidirectional,
that is only a (current) restriction if you use SASL for authentication.
(It meight even happen, that this restriction will be dropped sometime
in the future, at least I would not be surprized.)
As I said, I think there are reasons to go with either jabber:client or
jabber:server. It may more more a matter of picking one than choosing
based on some reasoning.
I always figured components were more like clients than servers. Clients and
components make single outbound connections, and construct and parse stanzas
for server routing. In contrast, servers do very little stanza manipulation
(and, depending on how your server is designed, even the roster stuff might
be in a component).
... you might even do the roster stuff on a different server, that is
connected using a s2s connection to the other server. I already set this
up once.
> It is stanza manipulation that really kicks your ass
when it comes to the different namespaces, and so sharing the same one as
clients would be useful I think.
In jabberd14 and as you (?) said at least in jabberd2 as well (don't
know the other servers) all handling is internally done in the same
namespace. This can be jabber:server (like in jabberd14 for the reasons
from above) or jabber:client (like in jabberd2) and does not make a big
difference for the server (it's just reading both namespaces as the same
namespace and when serializing XML it's using the expected namespace on
that connection to serialize the common internal namespace).
So if everybody else preferes the jabber:client namespace I can live
with that. But I'd prefere to use 'jabber:server'. Even if have a bit of
the expression, that people merely prefere 'jabber:client' just because
more people seem to work on clients or client connections were they are
more used with using 'jabber:client' as the standard namespace, than
working on s2s connections.
Matthias
