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.
> 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
>>> 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
>>> 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
>> * 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...
>>> 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