* Kim Alvefur <z...@zash.se> [2018-12-08 20:01]: > Anyways, if clicking a button sends an exact string given on the button > then there should be no ambiguity?
This is the second issue I have with this proto-XEP, because the i18n fails when clicking the button. You click "Ja" but your client sends "yes". This might be solvable by encouraging the implementations to mirror all labels from a button in respective i18n'ed <body> elements, and by changing the examples accordingly. My primary issue, however, is the already discussed Data Forms / ad-hoc commands elephant in the room. I'd really like to see a strawman proto-XEP implementing the same functionality on top of data-forms in messages, just to be able to compare the relative scariness. What I like about this one is the apparent simplicity, but the question of when to show buttons and how to handle "race conditions" seems rather complex. * Matthew Wild <mwi...@gmail.com> [2018-12-09 11:50]: > I don't know of a single mobile client with dataform rendering for > example (so they don't do custom IBR forms, they don't do ad-hoc > commands, and they certainly won't do forms inside messages). As a mobile client author, I see the complexity, but having a mechanism to implement polls, buttons and the like (and to fix IBR on the way) this would actually be a motivation for me to finally tackle data forms! With all this considered, I'm -0 on the proto-XEP. If we can fix i18n in data-forms, I'd rather go the more-complex but more-flexible route. If somebody comes up with a proto-XEP for data-forms-in-messages and that actually does look frightening to me, I'll +1 this one based on KISS. Georg
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
