[Standards-JIG] Re: Ad-hoc Commands and nesting

Trejkaz trejkaz at trypticon.org
Sun Jan 23 00:52:17 UTC 2005


On Sunday 23 January 2005 05:08, Nolan Eakins wrote:
> The idea that sent me back to this thread is about Service disco in
> general. I don't know if this is possible, but I don't see why it should
> not be: can a disco#items query return a list of items that are a mix of
> ~ say Pubsub nodes, adhoc commands, branches, clients, and any other
> service disco#item? This may require an additional attribute or two be
> added to the <item/> elements or a child element. Would this be desirable?

It can already be done without adding attributes.  The <item/> elements inside 
a disco#items query don't give any indication of their type.  A client needs 
to perform an extra disco#info query on each node to be completely sure what 
they do.

This is why in Psi, for example, the names of some items in the discovery can 
change a few seconds after appearing, because the names in the disco#items 
and disco#info queries were different due to naughty servers or whatever.  
Nothing illegal about it, it just confuses the user. :-)

My main issue with the JEP-50 spec is that at present, there isn't a way 
specified to do branches at all.  So what it effectively says is, "every item 
which comes back from the query is a command."  This is dangerous if someone 
_does_ put branches in, because any client which took this to be a way to 
optimise the number of queries they perform, may attempt to execute a node 
which is not actually a command, but a branch.

So we need _some_ way to do a branch, which needs to be specified in JEP-50 so 
that client implementations know they really do need to do a disco#info query 
to determine that something really is a command that can be executed.  At the 
moment I'm leaning towards the "branch" identity, because "command-list" in 
the registry is said to only exist on the (singular) "commands" node.

TX

-- 
             Email: Trejkaz Xaoza <trejkaz at trypticon.org>
          Web site: http://xaoza.net/
         Jabber ID: trejkaz at jabber.zim.net.au
   GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F  A62C B8C7 BC8B 037E EA73
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20050123/ca5a2ec2/attachment.sig>


More information about the Standards mailing list