Re: [Standards] XEP-0050: Ad-Hoc Commands

[jorge - w]

I'm not really proposing altering the existing standard, because it 
works fine for several tasks. It seems it would be just a matter of scope.


I know users writing commands looks weird, but we should consider that 
they will probably be using different clients at the same time and they 
would prefer doing the same in all of them. Anyway I just mean launching 
applications. Once they are launched, forms would take place in order to 
enter data.



El 18/10/2016 a las 9:43, Dave Cridland escribió:

On 18 October 2016 at 08:11, jorge - w  wrote:

I'm just trying to receive feeback from the community, since i have recently
joined it.


Sure - and it's appreciated.


In order to avoid client dependency, any programming should be done at
server side. I already know anything can be coded with no need for a
standard, I'm just exposing an idea, not a personal need.


Protocol designs that need no special support from the client are
really powerful - but they also have limitations.

We can encode almost everything as text, but XEP-0050 encodes any
command (or command sequence) as a series of form exchanges. It's not
quite as good, in as much as clients do need support for XEP-0050, but
they don't need any special support for any particular command.

On a similar note, MUC (XEP-0045) encodes everything using existing
exchanges of directed presence and messages. That's served us
incredibly well over the years, but it's also brought us into a
dead-end.

There's a balance to be made here.

But just as we think '45 can be improved, I'm open to the idea of '50
being improved or replaced too - but I'd like to see a concrete
design. Write something more formal, and ideally submit it as a XEP,
and we can compare the options side-by-side much better.



El 18/10/2016 a las 8:59, Kevin Smith escribió:

On 18 Oct 2016, at 07:54, jorge - w  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.

This seems to be conflating user interface with protocol, there’s nothing
stopping clients from doing parsing for :something in the text field and
turning it into adhocs behind the scenes.

That said, if this is something you believe is needed, the usual thing to
do is to write up a protoXEP and see what support it gets in the
community/Council.

/K
___
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
___

Re: [Standards] XEP-0050: Ad-Hoc Commands

[Dave Cridland]

On 18 October 2016 at 08:11, jorge - w  wrote:
> I'm just trying to receive feeback from the community, since i have recently
> joined it.
>

Sure - and it's appreciated.

> In order to avoid client dependency, any programming should be done at
> server side. I already know anything can be coded with no need for a
> standard, I'm just exposing an idea, not a personal need.
>

Protocol designs that need no special support from the client are
really powerful - but they also have limitations.

We can encode almost everything as text, but XEP-0050 encodes any
command (or command sequence) as a series of form exchanges. It's not
quite as good, in as much as clients do need support for XEP-0050, but
they don't need any special support for any particular command.

On a similar note, MUC (XEP-0045) encodes everything using existing
exchanges of directed presence and messages. That's served us
incredibly well over the years, but it's also brought us into a
dead-end.

There's a balance to be made here.

But just as we think '45 can be improved, I'm open to the idea of '50
being improved or replaced too - but I'd like to see a concrete
design. Write something more formal, and ideally submit it as a XEP,
and we can compare the options side-by-side much better.

>
>
> El 18/10/2016 a las 8:59, Kevin Smith escribió:
>>
>> On 18 Oct 2016, at 07:54, jorge - w  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.
>>
>> This seems to be conflating user interface with protocol, there’s nothing
>> stopping clients from doing parsing for :something in the text field and
>> turning it into adhocs behind the scenes.
>>
>> That said, if this is something you believe is needed, the usual thing to
>> do is to write up a protoXEP and see what support it gets in the
>> community/Council.
>>
>> /K
>> ___
>> 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
___

Re: [Standards] XEP-0050: Ad-Hoc Commands

[Dave Cridland]

On 18 October 2016 at 07:54, jorge - w  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  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
___

Re: [Standards] XEP-0050: Ad-Hoc Commands

[jorge - w]

I'm just trying to receive feeback from the community, since i have 
recently joined it.


In order to avoid client dependency, any programming should be done at 
server side. I already know anything can be coded with no need for a 
standard, I'm just exposing an idea, not a personal need.



El 18/10/2016 a las 8:59, Kevin Smith escribió:

On 18 Oct 2016, at 07:54, jorge - w  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.

This seems to be conflating user interface with protocol, there’s nothing 
stopping clients from doing parsing for :something in the text field and 
turning it into adhocs behind the scenes.

That said, if this is something you believe is needed, the usual thing to do is 
to write up a protoXEP and see what support it gets in the community/Council.

/K
___
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
___

Re: [Standards] XEP-0050: Ad-Hoc Commands

[Kevin Smith]

On 18 Oct 2016, at 07:54, jorge - w  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.

This seems to be conflating user interface with protocol, there’s nothing 
stopping clients from doing parsing for :something in the text field and 
turning it into adhocs behind the scenes.

That said, if this is something you believe is needed, the usual thing to do is 
to write up a protoXEP and see what support it gets in the community/Council.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0050: Ad-Hoc Commands

[jorge - w]

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

Re: [Standards] XEP-0050: Ad-Hoc Commands

[Dave Cridland]

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

Re: [Standards] XEP-0050: Ad-Hoc Commands

[jorge - w]

But I mean it might add some intuitiveness. I image that for a regular 
user it would be easier to write a simple sequence of characters in any 
group of clients he may choose (web, Android, desktop...) rather than 
looking for command execution (if available) on each of them.


For example, if a user wanted to run a script that interacts with 
another user he'd prefer to run it from the corresponding chat session. 
It could be sending links, playing games, or paying credits in a time 
bank application. I guess a bot can do it inside a room, not in a 
private chat.



El 17/10/2016 a las 14:49, Goffi escribió:

Le lundi 17 octobre 2016, 13:03:52 CEST jorge - w a écrit :

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.

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.

I hope I'm not missing something...

Regards

Hi,

There are lot of clients featuring XEP-0050, but it's often hidden in
discovery menu, not super intuitive.

XEP-0050 is one of my favorite XEPs, simple, generic, and powerful, with
structured data thanks to data forms, nothing to do with a IRC-style command.

If you want to do text commands, nothing prevent you to interpret sequence of
characters, any bot can do it, and it will work everywhere. But that's a poor
man solution in comparison to XEP-0050

Goffi
___
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
___

Re: [Standards] XEP-0050: Ad-Hoc Commands

[Goffi]

Le lundi 17 octobre 2016, 13:03:52 CEST jorge - w a écrit :
> 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.
> 
> 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.
> 
> I hope I'm not missing something...
> 
> Regards

Hi,

There are lot of clients featuring XEP-0050, but it's often hidden in 
discovery menu, not super intuitive.

XEP-0050 is one of my favorite XEPs, simple, generic, and powerful, with 
structured data thanks to data forms, nothing to do with a IRC-style command.

If you want to do text commands, nothing prevent you to interpret sequence of 
characters, any bot can do it, and it will work everywhere. But that's a poor 
man solution in comparison to XEP-0050

Goffi
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0050: Ad-Hoc Commands

[jorge - w]

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.


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.


I hope I'm not missing something...

Regards


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___