On 3/2/20 5:18 PM, Jonas Schäfer wrote: > On Montag, 2. März 2020 11:56:58 CET Marcos wrote: >> thanks for your comments, Florian. >> Florian Schmaus writes: >>> I think creating/canelling a reminder should rather be an ad-hoc command >>> and not an IQ. This way, clients do not need to implement another IQ >>> protocol-flow, but can re-use their (potentially) existing ad-hoc >>> infrastructure. >> >> This probably escapes from my current understandings of the protocol, so >> thanks for pointing it out and I'll try to have a read over IQ handling >> logic, specially at client side (an issue Andrew already exposed). > > Ad-Hoc commands would definitely be a way to do this. Using a specified > command name (like XEP-0401 does) would allow for automated entities to > interact with this and also gives immediate basic client support for clients > which already support Ad-Hoc commands. > > For clients which do not, and which also do not support Data Forms at all, > this will be more of a pain to implement even without offering extensive user > interaction.
I doubt that it will be much pain, and even if, I would consider implementing data forms and ad-hoc commands are worth the pain. > This is always a trade-off, and I’ve stated elsewhere that I consider data > forms a bad thing to have due to their lack of supporting arbitrary > structured > and dynamic data. I don't think I agree with that. They are flexible enough to serve a large portion of data-exchange use-cases. I am also not sure why they shouldn't support dynamic data. > And this specification needs timestamps, which are a kind of structured data. Right. I would suggest to use xep122 "data forms validation" to provide a client with the hint that this form field is a xep82 data time format. Clients could use this to show a data/time picker UI when this form field is selected. > For a naive Ad-Hoc client, specifying the timestamp in XEP-0082 format will > be > massively annoying for the user. Agreed, especially if no xep112 hint (cf. xep112 example 2) is used. But still better than a naive client not being able to participate at all IMHO. Not sure how massive the annoyance for the user would be, though. Guess it depends on the user. > For a client which adds specific support for > this ProtoXEP, the cost of doing so is likely less high than adding a custom > IQ support Correct: For a client (library) already supporting data forms, implementing an ad-hoc/data-form based protocol is far easier then implementing a pure IQ based protocol. >>> Also § 5.2 / Example 7 "Server sends a reminder" should include just a >>> <body/>, and not invent another <body/>-like extension element (<text/>). >> >> Makes sense. >> >>> The 'timezone' attribute in <date/> is not necessary, xep82 data-time >>> profiles already encode the timezone (the 'Z' at the end of the String). >> >> Indeed, this slipped in from an early write up where no reference to >> XEP-0082 was yet present. It has been already amended. > > Actually, timezones is a good keyword.For timestamps in the future, it is > generally better to use localtime+timezone specifier instead of a UTC > timestamp. After all, if you are in the Europe/Berlin timezone and set a > reminder for a year from now and Europe switches to UTC+2 all year round, you > don’t want your reminder to fire at the wrong hour. Fair point, but I believe the timezone is unnecessary and hence contributes to protocol bloat and potentially causes confusion. Clients could just set the right future timestamp taking the timezone into account. A note about this in the XEP sure would be sensible. - Florian _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
