[Standards-JIG] Ad-hoc Commands and nesting

Trejkaz trejkaz at trypticon.org
Tue Jan 25 12:49:00 UTC 2005

On Tuesday 25 January 2005 03:39, Matthew A. Miller wrote:
> 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.

I know, without adding anything too complicated, the trade-off is:
  (a) a cascaded menu, with lag to the server when expanding the menu
      unless you fetch them all up-front anyway, or
  (b) a menu with 150 items which can't fit on the screen.

But it's more than that.  The 150 items could easily contain multiple items 
with th same name (though obviously, different nodes), so structure feels 
necessary to give the user more idea of what they're actually executing.

I'm reluctant to encourage anything remotely like nested roster groups, that's 
for sure.  Part of me wonders whether the <identity/> could be reused for 
this purpose, only disco suggests that when an item has two identities, that 
the name attributes agree.

Maybe when I do end up with many commands, I will simply inform users to get 
at the commands directly via the discovery dialog in their favourite client.  
And perhaps I will merely use the commands node itself to contain a 
configuration command to choose which other commands appear on the main node.  
(sort of like customising a toolbar in a GUI application.)


             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/20050125/40d2c636/attachment.sig>

More information about the Standards mailing list