Am 29.09.2015 um 02:02 schrieb Evgeny Khramtsov <xramt...@gmail.com>:
> Thu, 24 Sep 2015 13:10:44 +0300 > PG Stath <pgst...@gmail.com> 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: > 1) Avatars: XEP-0084 vs XEP-0153 > 2) Time: XEP-0090 vs XEP-0202. Yes, there are still abandoned quite > popular clients with no support of XEP-0202. > 3) Filetransfer. Tons of specs. The transition might be HTTP > Upload + jabber:x:oob, until Jingle specs are finalized. > 4) MUC. Inventing MUC2 will result in the similar problems. The > transition will be painful due to MUC complexity. I agree, too. The list can go on: XEP-0054 vs. XEP-0292 (VCard) XEP-0256 vs. XEP-0319 (Idle/Last active time, clients now need to append both extensions) XEP-0136 vs. XEP-0313 (Archive) XEP-0049 vs. XEP-0223 (Private storage, e.g. how do clients know where XEP-0048 bookmarks are really stored?) XEP-0079 vs. XEP-0334 (Message Processing, I believe 100% of 0334 can be covered with 0079, so why a new XEP?) XEP-0191 vs. XEP-0016 (Blocking Users) XEP-0085 vs. XEP-0022 (Ok, to be fair, this transition was successful I guess) XEP-0249 vs. XEP-0045 (2 kinds of MUC invitations) XEP-0186 vs. XEP-0126 (How to deal with invisibility?) On top of that, different ways of storage or transports (e.g. as in XEP-0152) makes implementation not easier, especially for client developers. - Christian
