[Telepathy] future of Telepathy?

[Daniel Pocock]

On 25/04/16 06:21, Paul Wise wrote:
> [Please CC me on replies, I'm not subscribed]
>
> On Sat, Apr 23, 2016 at 12:43:05PM +0200, Daniel Pocock wrote:
>
>> Oddly enough, there is now a network/softphone called Ring[1] and so
>> telepathy-ring may become confusing, it may need to be renamed
>> telepathy-mobile or something.
> I don't think it is appropriate to stomp over the name of an existing
> project no matter how little time the upstream for another unrelated
> project spent on researching that the name might already be used. 

My comment wasn't suggesting whether such renaming would come about as a
result of stomping or some process of negotiation.

>> Telepathy is a modular framework, the link you provided is a
>> connection manager (CM) that appears to run within a Telepathy
>> system, it doesn't appear to be a fork or alternative to the core
>> Telepathy components.
> See pochu's response.
>
>>> Does Telepathy have a future?
>> Telepathy is currently in many Linux desktops.
> That doesn't mean it has a future, for that you need a community of
> people who care about the project, are working on the core code and are
> implementing new backends etc. Right now there doesn't seem to be one,
> I guess ever since Nokia died, Telepathy has been on life support,
> since it never saw use outside of Nokia/Jolla and the FLOSS distros.

Look at it from another angle then:

- are Linux desktops rushing to embrace or develop any alternative to
Telepathy?
- are there viable alternatives already?
- does any other product have any critical mass?
- does the improvement of individual connection managers (e.g. the new
ring.cx connection manager or a reSIProcate CM with proper support for
NAT) make Telepathy a whole lot more compelling?


>> There has been some talk about improving the GNOME Empathy front-end,
>> I'm not sure about the state of the KDE front-end, but they do work
>> as they are.
> Neither of those are part of the Telepathy project itself, they are
> desktop-specific user interfaces for it.


There is something of a chicken-and-egg problem here too.  People may
not make much effort to improve those front-end projects if the
back-ends (connection managers) all lack good NAT traversal.  That is
one reason why I'm actively engaging in improvement to the back-end.

Back-end developers may have concerns about those front-ends too, but
maybe we just have to take a leap of faith.

The big benefit to back-end developers is that making a CM for Telepathy
provides a way to get their protocol installed as part of a default
Linux installation rather than being something that users have to
manually install with apt-get, yum or whatever.  Metcalfe's law tells us
that this strategy greatly improves the value of all the connection
managers installed this way.

Regards,

Daniel