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