XMPP Council - 2018-04-19

  1. flow

    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.

  2. Kev

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

  3. Kev

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

  4. flow

    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

  5. Kev

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

  6. flow

    We probably have different definitions of "redundant"

  7. Ge0rG

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

  8. flow

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

  9. Kev

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

  10. Ge0rG

    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?

  11. flow

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

  12. Ge0rG

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

  13. flow

    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.

  14. flow

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

  15. flow

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

  16. flow

    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.

  17. jonasw

    maybe take that discussion to xsf@?

  18. Dave

    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.

  19. Ge0rG

    maybe take that discussion to standards@?

  20. jonasw

    or even that

  21. Ge0rG

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

  22. Ge0rG

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

  23. jonasw

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

  24. Dave

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

  25. Kev

    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.

  26. Ge0rG

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

  27. jonasw looks at aioxmpps Ad-Hoc implementation

  28. jonasw

    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".

  29. Kev

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

  30. jonasw

    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

  31. jonasw

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

  32. Kev

    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)

  33. Kev

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

  34. Kev

    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.

  35. jonasw

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

  36. jonasw

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

  37. Ge0rG

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

  38. jonasw

    Ge0rG, since "cancel" is implied, no

  39. jonasw

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

  40. flow

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

  41. flow

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

  42. Kev

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