On 18 October 2016 at 07:54, jorge - w <jwien...@gmail.com> wrote: > My view is that XEP-0050 is fine as an admin tool, just like XEP-0133. > > But what is fine for admins is not always the same for regular users. That's > why i think there should be a different interface for regular users mostly > aimed to external applications. Users might prefer :app_short_name to launch > them without the need for extra menus. >
I think it's somewhat amusing that you're trying to suggest that admins like a graphical form-based interface, whereas ordinary users would prefer a command line. My experience suggests the exact opposite, if anything. I follow how ":app_short_name" might work. What I don't understand is how one discovers that "app_short_name" exists, what it does, and what parameters can be used, and how those parameters are passed. Dave. > > > El 17/10/2016 a las 16:33, Dave Cridland escribió: >> >> On 17 October 2016 at 12:03, jorge - w <jwien...@gmail.com> wrote: >>> >>> I'd like to discuss about the scope of XEP-0050. According to Motivation >>> the >>> objetive is to expand Jabber beyond instant messaging. >>> However I see few XMPP clients feature command execution. I wonder if >>> another approach could be considered. >>> >> A number of clients do support remote command execution, but I agree >> it's something of a niche feature. >> >>> XEP-0245 introduces a different way of executing a command, just by using >>> a >>> sequence of characters (/me ). Why not taking a similar approach for >>> executing commands in general that will be addressed to the server? Gajim >>> does it internally, but I mean a standard that does not depend on client, >>> since it would be implemented at the server side. >>> >> "/me " is not a command; it's a presentation hint. We documented it >> mostly because it was in widespread usage already, and not because it >> was a particularly great design. >> >> But let's suppose we do commands entirely by fixed-prefix handling: >> >> * We need to have a way of unambiguously identifying commands. We >> cannot risk collisions, and our normal practise of using XML >> namespaces to avoid the need for a central registry won't really work >> here. >> * This in turn means that - positing a command "example" - we don't >> know if your "/example " command means the same as mine. >> * We also need a discovery mechanism for commands. We could of course >> use "/help ", but we'll need to format the text response carefully. >> Using a structured discovery mechanism needs support in the client, so >> that's out. >> * We'll have no support for structured data. We could, arguably, use >> further formatting to inject parameters - perhaps a ":" prefix, since >> we seem to be badly copying IRC anyway at this point. Again, we'll >> need to have this support in the discovery mechanism. >> >> So we're looking at a mechanism whereby we reserve, and hope, that >> "/help " will respond with a semi-structured (but human readable) >> command listing which will provide enough syntax cues that we can >> identify what the command does and how to invoke it, plus - ideally - >> a standards-based identifier for it. >> >> I'm willing to reserve judgement on such a concept until I've seen a >> specification for it, but do you think that's practical? >> >>> I hope I'm not missing something... >>> >>> Regards >>> >>> >>> >>> _______________________________________________ >>> Standards mailing list >>> Info: https://mail.jabber.org/mailman/listinfo/standards >>> Unsubscribe: standards-unsubscr...@xmpp.org >>> _______________________________________________ >>> >> _______________________________________________ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: standards-unsubscr...@xmpp.org >> _______________________________________________ > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
