[Standards-JIG] Ad-hoc Commands and nesting

Matthew A. Miller linuxwolf at outer-planes.net
Mon Jan 24 16:39:41 UTC 2005


The intention is for some entity (e.g. JID) to provide a generic 
mechanism for "doing stuff", and to discover that what stuff one can do 
as quickly as possible.  This is why there is a fixed node for the 
command-list, and all of the items associated to that node are only 
commands.

I am hesitant to change the current discovery protocol because of the 
overhead.  Currently, for a requester to find all the commands for a 
given JID, there is one disco#items transaction[1].  Even if the list is 
exceptionally large, the overhead of retrieving it is relatively small, 
and allows the requester to optimize in some way[2].

If we go to branching, this means a requester would need to disco#items 
the fixed node, then iteratively disco#info/disco#items each of those 
items (amortized however the requester prefers, of course). This is 
significantly more overhead, and for a payoff that doesn't (to me) look 
to be worth it.  Unless the user already knows what command they want, 
they'll be diving through this hierarchy anyway, with slightly more 
overhead, and a user-experience that (IMO) is painful.

This does not mean I'm opposed to it, but that my own experience with 
implementing JEP-0050 made disco-based hierarchies feel more painful 
than having a large menu/drop-down list/"outlook bar"/what have you.


-  LW

[1] If a JID does not support commands, then this disco#items request 
should be resulting in a <item-not-found/> or <not-acceptable/> error.

[2] There are a few possibilities here, although it may seem "hackish" 
(it doesn't to me, FWIW).  One I was favoring was to embed something 
similar to "nested roster groups" in the disco#info for the node 
"http://jabber.org/protocol/commands":
<query xmlns='http://jabber.org/protocol/disco#info'
     node='http://jabber.org/protocol/commands'>
   <identity category='automation' type='command-list'/>
   ...
   <present xmlns='http://jabber.org/protocol/commands#presentation'>
     <path-separator>/</path-separator>
   </present>
</query>

OR

<query xmlns='http://jabber.org/protocol/disco#info'
     node='http://jabber.org/protocol/commands'>
   <identity category='automation' type='command-list'/>
   ...
   <x xmlns='jabber:x:data' type='result'>
     <field var='FORM_TYPE' type='hidden'>
       <value>http://jabber.org/protocol/commands#presentation</value>
     </field>
     <field var='commands_path_sep' type='text-single'>
       <value>/</value>
     </field>
   </x>
</query>


Trejkaz wrote:
> Ripped out of JEP-50:
> 
> 
>>Example 3. Disco request for items
>>
>><iq type='get' from='requester at domain' to='responder at domain'>
>>  <query xmlns='http://jabber.org/protocol/disco#items'
>>         node='http://jabber.org/protocol/commands'/>
>></iq>
>>    
>>
>>Example 4. Disco result for items
>>
>><iq type='result' to='requester at domain' from='responder at domain'>
>>  <query xmlns='http://jabber.org/protocol/disco#items'
>>         node='http://jabber.org/protocol/commands'>
>>    <item jid='responder at domain' node='list'
>>          name='List Service Configurations'/>
> 
> [...]
> 
>>    <item jid='responder at domain' node='restart'
>>          name='Restart Service'/>
>>  </query>
>></iq>
> 
> 
> What I'd like to know is...
> 
> In the case of a server, there may be hundreds of administrative commands 
> available.  Obviously you can put them all in one gigantic list, but 
> selecting from a drop-down box of even a dozen commands feels painful 
> already.
> 
> Wouldn't it be possible to nest the command lists?
> 
> | <iq type='get' from='requester at domain' to='responder at domain'>
> |   <query xmlns='http://jabber.org/protocol/disco#items'
> |          node='http://jabber.org/protocol/commands'/>
> | </iq>
> | <iq type='result' to='requester at domain' from='responder at domain'>
> |   <query xmlns='http://jabber.org/protocol/disco#items'
> |          node='http://jabber.org/protocol/commands'>
> |     <item jid='responder at domain' node='cat-1'
> |           name='Command Category 1'/>
> |     <item jid='responder at domain' node='cat-2'
> |           name='Command Category 2'/>
> |   </query>
> | </iq>
> 
> And how does a client know they're command lists and not commands?  Easy:
> 
> | <iq type='get' from='requester at domain' to='responder at domain'>
> |   <query xmlns='http://jabber.org/protocol/disco#info'
> |          node='cat-1'/>
> | </iq>
> | <iq type='result to='requester at domain' from='responder at domain'>
> |   <query xmlns='http://jabber.org/protocol/disco#info'
> |          node='config'>
> |     <identity name='Category 1'
> |               category='automation' type='command-list'/>
> |   </query>
> | </iq>
> 
> The service said it was a list of commands, so we should do a disco#items 
> again, and so on and so on.  This can be relatively easily implemented as 
> either a set of drop-down boxes or a cascading menu.  Or, it can be easily 
> accessed via a service discovery screen such as Psi's.
> 
> Any comments?
> 
> TX
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mail.jabber.org/mailman/listinfo/standards-jig

-- 
-  LW

GOT JABBER™? <http://www.jabber.org/>



More information about the Standards mailing list