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 _______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/telepathy
