Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
schmittlauch opened this issue Feb 1, 2018 · 2 comments

Comments

@schmittlauch
Copy link

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
Copy link
Author

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
Copy link
Member

Kaffeine commented Nov 5, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants