On 29 September 2015 at 08:12, Christian Schudt <[email protected]> wrote:
> > Am 29.09.2015 um 02:02 schrieb Evgeny Khramtsov <[email protected]>: > > > 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: > > 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) > There's also XEP-0154, which is deferred but not deprecated. One server-side vCard implementation I wrote got amazingly complex trying to design for this... My understanding is that's been fixed now. But XEP-0292 does not offer any compatibility path back to XEP-0054 either; we really need to fix this. > XEP-0256 vs. XEP-0319 (Idle/Last active time, clients now need to append > both extensions) > Can we do server translation of this? At least for the Idle case? > XEP-0136 vs. XEP-0313 (Archive) > XEP-0136 is pretty much dead, I think, and XEP-0313 can be built server-side on top of XEP-0136 stores with some effort. > XEP-0049 vs. XEP-0223 (Private storage, e.g. how do clients know where > XEP-0048 bookmarks are really stored?) > Private storage in these cases should be mapped to the right PEP node transparently, so clients don't have to guess. > XEP-0079 vs. XEP-0334 (Message Processing, I believe 100% of 0334 can be > covered with 0079, so why a new XEP?) > We should definitely move XEP-0079 to deprecated. It's horribly complex, and nobody implemented it that I can recall anyway. > XEP-0191 vs. XEP-0016 (Blocking Users) > XEP-0016 covers three cases, in fact: - the blocking of users which is covered by XEP-0191. - invisibility, covered by XEP-0186. - weird stuff nobody used. We should deprecate it. XEP-0085 vs. XEP-0022 (Ok, to be fair, this transition was successful I > guess) > Yes, definitely done; though we should consider revisiting XEP-0085 in MUC cases. > XEP-0249 vs. XEP-0045 (2 kinds of MUC invitations) > Complex. We want to send a message direct from one user to another - the XEP-0249 case - but we also often need the MUC to know a user is to be invited - the XEP-0045 case. > XEP-0186 vs. XEP-0126 (How to deal with invisibility?) > > As above; I have no idea why a client developer would prefer to use XEP-0016 manipulation for 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.
