Mon, 12 Oct 2015 22:21:38 +0200 Ralph Meijer <[email protected]> wrote: Technical arguments, finally :)
> One of the major problems on the client side, is that implementing a > proper user interface for this protocol is a challenge and unlikely to > be very intuitive. Have a look at Gajim's implementation. It seems to > do everything the protocol specifies, but it is very confusing. See > also <https://trac.gajim.org/ticket/3357>. Suggested solutions in > that ticket include breaking it down into simpler dialogs for > specific use cases and then create/modify privacy lists rules for the > result. This is a problem, because not only does the client developer > have to think about proper abstractions, *every* client developer has > to do the same work in their own implementation. > ... > As I mentioned before, deprecating a XEP just means that new > implementations are not encouraged *by the XSF*. It means that the > people currently on the Council have decided, based on input from the > community, that the general consensus is that this particular > enhancement is no longer the best way to go about things. It does not > mean everyone agrees with that. It does not mean you can not start new > implementation. It does not mean you can not use it. > ... > The next step might be obsoletion. This means that the XSF thinks that > the protocol should not be deployed or used any longer. If you want, > of course you can still do that, though. The arguments are convincing, I admit. I hope XSF will find a solution for blocking messages from unsubscribed users before the XEP moves to obsoletion state.
