[standards-jig] disco, x:data, etc...

Alexey Shchepin alexey at sevcom.net
Thu Feb 20 18:57:58 UTC 2003


Hello, Thomas!

On Thu, 20 Feb 2003 10:12:22 -0600, you said:

 MAM> First, the admin problems that Alexey is trying to solve are exactly what
 MAM> x-commands is designed for.  Why not just use x-commands?
 >>  Because:
 >> 
 >> 1) x-commands not indended to include other namespaces than x:data

 TM> Have you read the JEP?  Section 3.4 clearly states that pretty much any
 TM> extension can be used in a <command/> element.  If the JEPs focus was
 TM> limitted to a x:data launcher, I'm pretty sure it would get no where.

Sorry, I misread this part, then question is what namespaces called as
"extension"?  In this section writen that "The payload can be any elements in
an *extension* namespace (such as "jabber:x:data")...".  

 >> 2) x-commands adds "node" attribute, but also adds useless in this case
 >> additional element, namespace and more hard processing from both client and
 >> server side.

 TM> I'm confused now, are you against the node attribute in commands?

Nope, I'm against using x-commands to simply address iq stanza to specified
node.

 TM> Personally, I find the commands system simple and clear.  I'm coding it
 TM> into JabberStudio's jabber interface to provide interaction with all of
 TM> the managers, and so far I have no problems with it.

I not say that this is hard, but for task that I wont to solve, this is not the
best way.  Look at examples below.

 MAM> Second, FORM_TYPE (currently) does not fully address Alexey's issue,
 >>  IMHO it address jep-0004 issue.  x:data is used both as human-readable (i
 >> mean human can use it when it showed in client) and as machine-readable
 >> (e.g. in negotiation protocol).  But:
 >> 
 >> 1) From machine side it contain useless elements (like instruction, title,
 >> and field with type fixed) -- this is not bad, but shows that it not only
 >> for machine.

 TM> x:data was not designed for machine usage,

Then why it used in feature negotiation?

 TM> mostly because nothing is fixed, but JEP-68 is a proposal to make that
 TM> more clear.

 >> 2) From client side it looks like a non-extensible and non-flexible
 >> protocol, because:
 >> 
 >> a) Field types set are fixed.  And fixed with some strange types like
 >> "jid-single" and "jid-multi".  Why so many attention to JID?  Of course in
 >> some situation we need to enter JID, or list of JIDs, but sometimes we need
 >> to enter date, time, etc...  IMHO better replacement for this looks like
 >> this: <field type="text-single" subtype="jid" .../> and for date <field
 >> type="text-single" subtype="date" .../>.  Or even better to make list of
 >> options for each field type.  And IMHO JEP-0068 looks better if it will
 >> have no fixed var names for each FORM_TYPE, but will have additional
 >> attribute that points to it meaning in given FORM_TYPE.  This helps if this
 >> form can have not fixed number of elements (for which we must use different
 >> var names).

 TM> I personally am not a big fan of having the few fixed types that are
 TM> there, but we needed some amount of compromise to get it out the door.

And now it have status "Final", in which hard to change something :(

 TM> Some people are looking at new JEPs to layer on better type control and
 TM> verification.

Maybe better to have one "Final" JEP that solve one issue, than many?  I simply
want to force to continue work on this JEP, and assign "Final" status only
after it will be more generic.

 >> b) If we want to display to human list of fields, then we need to know that
 >> for human hard to search requred field from list of 30 values, it should
 >> contain no more then 10 elements to be easily understandable.  In
 >> interfaces this usually solved by grouping of fields.  So if we have
 >> <instruction/> and <title/> that intended only for displaying for human,
 >> why not to have <section/>, so clients can handle it e.g. by displaying
 >> sections in different tabs, by making something like table of contents in
 >> beginning of list, or by ignoring it.

 TM> I'm missing something, are you wanting to group parts of the form?  Or
 TM> section off items in a list?

By sectioning of field list we not separate this fields in groups?  I.e.:

  <x xmlns='jabber:x:data'>
    ...
    <section name="address"/>
    <field .../>
    ...
    <field .../>
    <section name="another group"/>
    <field .../>
    <field .../>
    ...
  </x>

 TM> As a final note, I'm still failing to see how the commands system doesn't
 TM> meet your requirements.  Do you have a more clear statement about where it
 TM> fails?  I think it's important that any commands issues are figured out
 TM> because it can be a very important building block in the future.

OK, below I show examples of getting statistics from entire ejabberd server and
from one of his nodes.

How I do it now:

Client requests statistics from server:
<iq id='5'
    to='e.localhost'
    type='get'>
  <query xmlns='http://jabber.org/protocol/stats'/>
</iq>

Server responds:
<iq from='e.localhost'
    to='test at e.localhost/tkabber'
    id='5'
    type='result'>
  <query xmlns='http://jabber.org/protocol/stats'>
    <stat name='users/online'/>
    <stat name='users/total'/>
  </query>
</iq>


Client requests statistics from node "running nodes/ejabberd at alex.sevcom.net":
<iq id='10'
    to='e.localhost'
    type='get'>
  <query xmlns='http://jabber.org/protocol/stats'
         node='running nodes/ejabberd at alex.sevcom.net'/>
</iq>

Server responds:
<iq from='e.localhost'
    to='test at e.localhost/tkabber'
    id='10'
    type='result'>
  <query xmlns='http://jabber.org/protocol/stats'
         node='running nodes/ejabberd at alex.sevcom.net'>
    <stat name='time/uptime'/>
    <stat name='time/cputime'/>
    <stat name='users/online'/>
    <stat name='transactions/commited'/>
    <stat name='transactions/aborted'/>
    <stat name='transactions/restarted'/>
    <stat name='transactions/logged'/>
  </query>
</iq>

===============================================================================

How I want to do this:

Client requests statistics from node "running nodes/ejabberd at alex.sevcom.net":
<iq id='10'
    to='e.localhost'
    tonode='running nodes/ejabberd at alex.sevcom.net'
    type='get'>
  <query xmlns='http://jabber.org/protocol/stats'/>
</iq>

Server responds:
<iq from='e.localhost'
    fromnode='running nodes/ejabberd at alex.sevcom.net'
    to='test at e.localhost/tkabber'
    id='10'
    type='result'>
  <query xmlns='http://jabber.org/protocol/stats'>
    ...
  </query>
</iq>

===============================================================================

How to do this with x-commands (if we can call stats namespace as "extension
namespace"):

Client requests statistics from node "running nodes/ejabberd at alex.sevcom.net":
<iq id='10'
    to='e.localhost'
    type='get'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='running nodes/ejabberd at alex.sevcom.net'>
    <query xmlns='http://jabber.org/protocol/stats'/>
  </command>
</iq>

Server responds:
<iq from='e.localhost'
    to='test at e.localhost/tkabber'
    id='10'
    type='result'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='running nodes/ejabberd at alex.sevcom.net'
           status='completed'>
    <query xmlns='http://jabber.org/protocol/stats'>
      ...
    </query>
  </command>
</iq>

===============================================================================

So we have three ways: include "node" inside <query/>, include it inside
toplevel stanza (iq, message and presence), or include iq payload inside
another namespace that adds "node".  Now try to compare this three ways and say
why you still prefer last way.  For me last way looks most complicated.


PS: Imagine that you develop Jabber protocol in very earlier stage, when it not
have "id" attribute inside "iq" stanza, e.g.:

<iq to='e.localhost'
    type='get'>
  <query xmlns='http://jabber.org/protocol/stats'/>
</iq>

But we want to track queries/responses.

One people suggest to do this:

For query with "id":
<iq to='e.localhost'
    type='get'>
  <track xmlns='jabber:iq:id' id='id1'>
    <query xmlns='http://jabber.org/protocol/stats'/>
  </track>
</iq>

Another people suggest to do this:

<iq to='e.localhost'
    type='get'>
  <query xmlns='http://jabber.org/protocol/stats'
         id='id1'/>
</iq>

And third people suggest this:

<iq to='e.localhost'
    id='id1'
    type='get'>
  <query xmlns='http://jabber.org/protocol/stats'/>
</iq>

What are your choice?  Why now we use last way?  Because noone suggest first
way first?

Hope it helps.




More information about the Standards mailing list