On 22.02.2018 10:28, Kevin Smith wrote: >> On 21 Feb 2018, at 18:50, Florian Schmaus <f...@geekplace.eu> wrote: >> On 06.08.2015 17:42, Goffi wrote: >>> My guess is that "execute" should be equivalent to "complete" when >>> "next" is not possible (but what if "complete" is disabled too ?). >> >> I think it is a little design weakness of XEP-0050: Ad-Hoc Commands that >> we have 'next' and 'execute'. It appears the whole protocol would be >> much simpler and less confusing if we just had 'execute’. > > Execute is convenient - it’s not an action of its own per se, it’s just > saying which of the provided actions is used by default (e.g. will be run > when the user hits Enter), but allowing it to be sent as an action= value > could have been better thought-out, I suspect (even then, it’s useful for the > first stage of the form). So I suspect the underlying issue described here is > UIs wrongly showing independent buttons for Execute and whatever Execute > should mean.
No, it is about simplicity and that I don't see why there shouldn't be a
combined *action* of 'next' and 'execute'. It is not about and unrelated
to the existence of the 'execute' attribute.
>> But this is unlikely to change ever. So here is how I understand it:
>>
>> - 'execute' always gets you into the next stage, and iff 'next' is an
>> allowed action, then 'execute' is equivalent to 'next', or otherwise it
>> is equivalent to 'complete’.
>
> I think that if we follow what 50 says, we actually reach the conclusion that
> if execute isn’t set on actions, it’s equivalent to next, which may be
> disabled. Which basically means that an actions list not including next and
> not including an execute value is saying “The default is next, and it’s
> disabled”, which is more or less a broken xep 50 command so the responder
> shouldn’t send it. Changing to have the default switch to complete if there’s
> no next is probably not harmful, although is a change in behaviour from what
> we have.
The question is: (1) Do we want to allow 'execute' to be at a given
point equivalent to a disabled action, which, when used, would result in
a bad-command error response, *or* do we want to avoid that by either
(2) Specifying that execute → next, if 'next' is not disabled
→ complete, otherwise
(3) Specifying that the responder must always provide an 'execute'
attribute if 'next' is a disabled action.
I'd love to go with either (2) or (3), but if you assume that (1) is
currently xep50 compliant, then this means a backwards incompatible
change, which would require a namespace bump.
A compromise would probably be only recommending (3) in the XEP.
- Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
