[standards-jig] disco, x:data, etc...
alexey at sevcom.net
Tue Feb 18 20:25:20 UTC 2003
On Sun, 16 Feb 2003 13:49:32 -0800, you said:
MAM> Hola, First, the use of x:data you have is not "as spec". x:data is not
MAM> meant to "stand alone" in the form you are using it.
Where in spec writen that I can't do this? :)
MAM> Rather, this usage is exactly what x-commands (JEP-0050) was designed
MAM> for. You should look into using x-commands where you have stand-alone
MAM> x:data forms.
X-commands only adds session id and status, which I not need in this situation.
And I don't like to use dummy namespaces like iq:register to include x:data
inside it (in case when using only x:data this namespace is really dummy).
MAM> As for making "node" part of the globally addressing system, I don't
MAM> think it necessary.
Yes it not necessary, but many not necessary things make life better :) Using
XML in Jabber protocol is also have not been necessary, but this make protocol
much better than e.g. when using IRC-like string-packets with strange format.
MAM> "node" was not intended as part of the global addressing. It was
MAM> intended as a way to report non-addressible items via disco.
Look to JID and "node" as to IP and port in tcp/ip addressing schema. Each
router looks only to IP (s/router/not advanced router/ :) and when packet
transferred to tcp/ip entity, OS on this entity looks to port and sends packet
to program inside it. Same with Jabber: servers route packets by JID to jabber
entity, and this entity can contain some subservices, to which packet is routed
by node. Without "node" Jabber enity can't separate information that returned
e.g. by disco or by stats. This is why "node" appears in disco -- in MUC
exists too many things to be returned by discovery, so we need way too separate
it in logical groups. And this is reason why I add support of node in stats
namespace (I mean in ejabberd and Tkabber) -- because this statistics is getted
from diferent parts of ejabberd, and it better looks when it is separated in
the same way.
MAM> I made each command a disco node because they are not directly
MAM> addressible, but wanted to make better use of disco for discovery and
MAM> reporting. You address the entity, not the command. To explicitly
MAM> synchronize with disco, x-commands uses "node" to identify the specific
MAM> If you find the need to address a "node" globally, it would be better to
MAM> make it an addressible entity (use only the JID)
Any good ideas how to make this?
MAM> and leave the use of "node" for items that should not be directly
MAM> communicated with.
Why we need node to which we can't communicate? :)
More information about the Standards