On 29 September 2015 at 01:02, Evgeny Khramtsov <[email protected]> wrote:
> Thu, 24 Sep 2015 13:10:44 +0300 > PG Stath <[email protected]> wrote: > > > In general I think that XMPP might be missing developers not because > > features are missing but because of non compatible extensions lists > > and extension implementations among different libraries, servers and > > applications. > > Totally agreed. As a note, I think the list of deprecated XEPs should be > revised and a transition mechanism should be developed. The specs are: > Thanks for this list. Quick thoughts applying to all of these: a lot of these cases (some here, some in Christian's list) are where PEP services on supposedly modern servers have been treated as a second-class citizen - not being persistent, lacking all but the barest minimum of XEP-0060 features, not adhering to the spec. I'm not sure any of the mainstream server developers can take any kind of moral high-ground and blame the client developers for lagging behind given this. This single thing has held back real-world deployment of about half our modern specifications; many of which make unwarranted assumptions that the server developers will implement the specs. > 1) Avatars: XEP-0084 vs XEP-0153 > In principle, setting (via whichever flavour of vCard applies) an avatar should update it everywhere. > 2) Time: XEP-0090 vs XEP-0202. Yes, there are still abandoned quite > popular clients with no support of XEP-0202. > Supporting genuinely ancient clients is a general problem; I think we can address this by IQ protocol translation, but I imagine I'll get push-back from server developers there. > 3) Filetransfer. Tons of specs. The transition might be HTTP > Upload + jabber:x:oob, until Jingle specs are finalized. > File transfer, on the other hand, could very usefully be done via protocol translation. Converting SI to Jingle and back again - or even terminating Jingle in the server and translating to HTTP - really feels like it should be practical. > 4) MUC. Inventing MUC2 will result in the similar problems. The > transition will be painful due to MUC complexity. > That's true. I think it's unavoidable, but I think we should ensure we're able to offer '45 interfaces to MUC2 chatrooms. Dave.
