Hi, This should be an extension to dataforms, that way it becomes much more useful.
Otherwise it will go fast into the same direction, first we have only a button, then some people request some labels, and finally some other fields, at which point everyone will ask itself why is this button element not an extension of a dataform. I see really no argument why this should not be in dataforms, every half serious client already has to support some limited kind of dataform understanding and parsing, so i dont see the way it is now as easier to implement. Regards Philipp Am Sa., 8. Dez. 2018 um 12:13 Uhr schrieb Jonas Schäfer <jo...@wielicki.name >: > On Donnerstag, 6. Dezember 2018 20:43:07 CET Jonas Schäfer wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: Simple Buttons > > Abstract: > > This specification provides a way to send simple buttons. > > > > URL: https://xmpp.org/extensions/inbox/buttons.html > > > > The Council will decide in the next two weeks whether to accept this > > proposal as an official XEP. > > I am torn on this. > > I like the simplicity. However, I am worried that we end up with a half- > solution which will quickly have to be extended by folks who request more > features; and this solution at hand isn’t particularly extensible. > > My favourite example is a monitoring bot which posts an alert and offers > buttons such as "Silence for N minutes", where N is a variable. With the > current proposal, the bot would have to offer a fixed set of values for N, > or > the users would have to use manual text input (which *might* be fine, > actually). > > What I like about this proposal is that it gracefully falls back to plain > text > only. It can also interact (although this was not written down) with > XHTML-IM > in the same way memberbot does (by marking up the answer options as links > to > xmpp:bot@foo.domain?body=yes (I think) for example). > > It is also reasonably simple to implement. It needs some editorial work > though. > > I happen to know that there was a concurrent proposal which used a data > form > with a list-single field where each option represented a button. The > client > would then send the filled out form to indicate which button was pressed. > This > would also be simple to implement and might be able to interact with > clients > which already offer the processing of arbitrary data forms in a stream of > messages. > > The data forms might be more extensible, but probably still need some > protocol > around them to make them actually useful as "buttons with variables" (see > above). > > kind regards, > Jonas_______________________________________________ > 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 _______________________________________________
