XMPP Council - 2018-04-19

Dave, right, that is at least misleading if not a contradiction. But I'm not sure if my conclusion would be to get rid of the 'execute' action all together. My approach would be to make it an always possible action, in order to improve the usability of xep50.

The thing is, execute's entirely redundant and as-specced is broken.

So while we could fix it, it would still be redundant.

If you assume 'execute' to be always 'next', then yes, it is entirely redundant. If you make it a "smart" action which always points to the next likely action (which is what my PR does), then it is IMHO no longer redundant and a worthwhile feature

It's still redundant, because it's still an extra action that doesn't do anything different to the existing actions.

We probably have different definitions of "redundant"

Maybe it's just an awkward and misleading way to tell the client which action is the default one?

Ge0rG, right now, I'm more concerned with the action, not the attribute

Ge0rG: We have the mechanism for specifying the default already, the execute action doesn't do that.

So the execute attribute is the default next action, and the execute action is... some always-present default action that needs to be injected by the client?

Ge0rG, xep50 makes multiple statements about the execute attribute and action. Let me wikify it for your, one moment please.

flow: I've skimmed through the xep now, thanks

Ge0rG, I think it comes down to the statements "The "execute" attribute specifies what the action "execute" is equivalent to." (in 4.2) and "The action "execute" is always allowed, and is equivalent to the action "next"." (in 3.4) contradicting each other.

See also https://wiki.xmpp.org/web/XEP-Remarks/XEP-0050:Ad-Hoc_Commands

So I've pushed a small change to my PR: https://github.com/xsf/xeps/pull/591

Now the only difference between Kev's PR and mine is that Kev allows "execute" to be an invalid action, whereas I specify a sane fallback so that you can simply always use "execute" as action.

maybe take that discussion to xsf@?

So I don't see the utility of an execute action given we always know what the default action presented in the UI should be.

maybe take that discussion to standards@?

or even that

Dave: I agree. Conceptually, the execute action is redundant and should best be removed.

However, I have no idea about the installed base and how it would be affected

deprecating the use and straightening the definition would be the best course of action then?

Ge0rG, Sure, but deprecating it seems the action here.

Ge0rG: Given no-one understands the execute command at the moment, including the author, given the text, I think it's reasonable to believe the installed base is broken. Particularly as this was what caused the thread in the first place.

Kev: this is just an assumption, and I'm hesitant to make changes to a Draft XEP that might break even more things.

it seems I happily operate on the basis of "Execute is a sane default for the action to do because it’s always allowed" and "the using protocol will know what’s needed better than the base library does".

jonasw: Which is broken, because Execute isn't always allowed, because sometimes it's Next, which doesn't exist ;)

and the example UI I made doesn’t care about EXECUTE at all and only shows the allowed subset of cancel, next, prev and complete buttons

(sorry for caps, that’s the constant name)

Ge0rG: There are three options: 1) Leave everything broken 2) Fix it by specifying the redundant action (possibly breaking already broken implementations) 3) Fix it by deprecating execute (possibly breaking already broken implementations)

I think we may as well go for the conceptually Right solution here, which is (3).

jonasw: Yes, that's the sane UI. For anything UI based I can't imagine why you would ever send execute for a multi-action form.

I’m all in for (3) by the way :)

although, remember that the execute action is used to *start* an Ad-Hoc session :)

Does (3) imply that the service always must provide at least one <action>?

Ge0rG, since "cancel" is implied, no

but it would make sense for a service to prefer status="completed" + an (error) message over not supplying any actions.

So (3) would mean "execute" becomes a special case action that can only be used to initiate a command?

Note that we could possibly also do (2) and (3)

> So (3) would mean "execute" becomes a special case action that can only be used to initiate a command? I think it does.