[next] Extensibility of telepathy - adding new interfaces for new features

[schmittlauch]

I just found a discussion about telepathy usage in Gnome and matrix.org and one point which became very clear there is that nearly everyone seems to be annoyed with the current state of telepathy, many wanting to abandon it completely.

One thing also hindering the further use of Telepathy nowadays is the mismatch of modern-day IM features and the old-style Telepathy API.

Therefore I propose that the telepathy-next spec needs to include a mechanism for extensibility. In case new features arise modules and dbus interfaces could be worked out and then documented and specified. Other connection managers requiring the same features hopefully use the same proposed extension.

The danger of adding a modular extension system to a protocol over just keeping a monolithic spec is getting unmaintainable diversification among different clients and servers, as it used to be the case with XMPP and the XEPs at some point. But I'm just afraid that a top-down spec architecture is just to slow and unflexible. Newer stadards may just adopt a certain set of extensions as core spec features later.

Different models to look at may be the XEP process or the modular approach of matrix.org

[schmittlauch]

Btw, because of these shortcomings of the current telepathy spec regarding new protocols I think "bring telepathy-next to a modern usable level first" is more likely to be successful than "try to attract more developers to telepathy first by pushing connection managers based on the old spec"

[Kaffeine]

Btw, because of these shortcomings of the current telepathy spec regarding new protocols I think "bring telepathy-next to a modern usable level first" is more likely to be successful than "try to attract more developers to telepathy first by pushing connection managers based on the old spec"

Exactly. I'm working on this.