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.

El 17/10/2016 a las 16:33, Dave Cridland escribió:
On 17 October 2016 at 12:03, jorge - w <> 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
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

Standards mailing list

Standards mailing list

Reply via email to