Hi Daniel, thanks very much for your feedback. I'd like to improve the XEP text to make the points clearer to understand.
* Daniel Gultsch <[email protected]> [2019-01-08 18:31]: > I’m not sure. Is the intent of the XEP to keep me reliably connected > to a MUC or is it intended to figure out if I’m connected to a group > chat? It's the latter. I've reviewed the abstract and the intro section, and I have the feeling that they both made this point rather clear. While I understand there is a need to solve the former problem, it's not the focus of this XEP. Do you have a wording suggestion for reducing the confusion? Should I add a sentence along the lines of | This extension can not ensure that a client remains reliably | connected, merely detect a disconnect. > If the intent of the protocol is to keep me connected to a MUC I’m > missing on on very crucial information like: > * How often do I ping? > * What time out do I use? These two are highly dependent on the kind of data connection you have, and it's hard to provide generic guidelines. In my implementation, I have both set to 15 minutes, but I can see an argument for higher as well as lower values. A sane combo for a mobile client would be 45min/2min as well, whereas a stationary desktop client could get along with 5min/30s. Should I add an indication of those possibilities into the XEP text? > * Does the time out increase when i’m in smack hibernation? When you are in hibernation, you shouldn't send any time-critical packets at all. If you do, you should probably base the timeout not on when you generate the stanza, but when it's actually sent after the resumption. To me this feels like obvious from how 0198 works, but I can add a sentence about that to the Business Rules. > * What do I do when i notice I’m no longer connected? This is adressed in §3.2: | - Any other error: the client is probably not joined. | - Timeout (no response): the MUC service (or another client) is | unreachable. The client may indicate the status to the user and | re-attempt the self-ping after some timeout, until it receives | either an error or a success response. From your remark I suppose I should change the first one into "... and should perform a re-join.". Is there anything else that needs to be clarified? > * Do I try to reconnect? How many times? In what interval? Is there a > maximum number of retries? Like with the timeout question above, this is highly dependent on your implementation. My implementation attempts to rejoin every 15mins, as part of the periodic self-ping check timer. I considered that as a good trade-off between battery consumption, responsiveness to the user and probability of still having enough MUC history to not miss anything. > * Do i still ping the group chat even if my app is in background or in > Push-Hibernation? > * Do I need a push from the server in #ping-interval to wake up my app > to allow it to ping the muc server? The interaction with Push is a very interesting area that I haven't had the need to cover yet. While you are in hibernation, you obviously can't ping any MUCs, so the first moment you can do it is after you are woken up. From a workaround-for-the-workaround perspective, it makes some sense to have a periodic wake-up that is triggered after you haven't been woken up for a certain time (1hr? 2hr? 24hr?), which will tell the client to perform a round of MUC pings. But if we look into the big picture, it would make much more sense to allow Push support on the MUC component, implement it in all servers, deploy it everywhere and then to get woken up by the MUC if you aren't a participant any more and "important" traffic is sent. But this is something for XEP-0357. > I’m unsure what problem it aims to solve so I can’t judge if it solves > that problem. I could imagine it is one of those, or maybe even all of them: - https://github.com/siacs/Conversations/issues/1671 - https://github.com/siacs/Conversations/issues/2690 - https://github.com/siacs/Conversations/issues/2983 Kind regards, Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
