Hi Steve, On Dienstag, 13. Juni 2017 17:08:00 CEST Steve Kille wrote: > I've just made changes for MIX 0.9.3, in which I have attempted to address > the three issues raised here. The approaches are simple and have not > added a lot of text.
From <https://github.com/xsf/xeps/compare/ master...stevekille:MIX#diff-46551996fe454185b68cb3f084c2e18fR2426>: > The server receiving the message will then deliver the messages to all > online clients with status available and a non-negative resource priority. I think the new wording here excludes any client with e.g. away, na, dnd or xa status from receiving MIX messages. That sounds like overkill (I’m not even sold on not receiving MIX messages with negative presence priority actually). From <https://github.com/xsf/xeps/compare/ master...stevekille:MIX#diff-46551996fe454185b68cb3f084c2e18fR2550>: > When a client adds MIX capability, additional information needs to be > provided by the server. To support this, a server MUST maintain > information about client MIX support status. When a server detects this > change it needs to update the roster which it MAY do incrementally or by > sending all of the roster. Could you elaborate how that works in the following scenario: Alice uses the client A, version 2.0 on her desktop and client B, version 1.0 on her phone. B 1.0 does not support MIX, but A 2.0 does. She is connected with both clients in parallel. She chats with both, but uses MIX only on her desktop with A 2.0. She has some MIXes bookmarked. Then she updates B on her phone to version 2.0, which finally supports MIX. Since B is mobile oriented, it uses roster versioning and asks the server for an incremental roster update when connecting. How exactly does the know that B did not support MIX on the last connection, but does now? I.e. how does the server recognise the "same" client on different connections? One thing I could imagine is for the server to include that information in the roster version. E.g. if it usually versions the roster with incrementing numbers, it could add "+mix" to the stringified number if MIX entries are included. This would allow it to recognise that the client has or has not seen a roster version with MIX and can create the diff accordingly. It took me a while to come up with this idea, so maybe it makes sense to add that to the wording. Also I have never written a server-side roster implementation, so I’m not sure if this is even a realistic way of doing things. I‘m still not happy with the extra round-trip required by the server for discovering the feature before responding with the roster, but from discussion in xsf@ (if I recall correctly, mainly with Dave), this may be a general problem we’d like to solve in a different protocol (like gratuitous entity capabilities sent by clients to the server before presence or something similar). > I have not pushed as a PR because of namespace numbering. It seems > likely that if a change is pushed every time we make a protocol tweak, > there is going to be a serious problem of namespace number proliferation. > > I think the options are: > > 1. Keep changes on a working branch and defer pushing. This gives less > visibility of work in progress. > > 2. Push and increment namespace. Problem noted above. > > 3. Push the PR and leave version number on mix:0. I think this may be > the pragmatic solution, provided it does not cause a problem for those > coding. This is a general question. In software library development, one would have a major update (here: things which require a namespace bump) branch and a minor update (here: things which do not require a namespace bump) branch, with the minor changes continuously flowing in the currently supported release. However, the XEP process does not make it easy to have these two branches exist in parallel in a manner which allows easy viewing and discussing. In this particular case, I’d suggest seeking consensus`from those who work on implementations. Or maybe someone deeper in the XSF has knowledge about any requirements in the process regarding this, I haven’t looked it up. kind regards & thanks, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
