[Telepathy] How to name Ring.cx Telepathy Connection Manager

[Daniel Pocock]

On 11/06/16 08:35, George Kiagiadakis wrote:
> On 06/10/2016 06:55 PM, Daniel Pocock wrote:
>>
>>
>> On 10/06/16 17:49, Stepan Salenikovich wrote:
>>> Hi,
>>> I'm a developper on the ring.cx <http://ring.cx> project. There are a
>>> couple of GSoC students working on a Telepathy CM for Ring.
>>>
>>> I posted this question on the Ring mailing list, but sadly didn't get
>>> any responses, so I'm hoping maybe the Telepathy list is more creative :)
>>>
>>> There is also a question about how to name the "Ring" protocol. Ring
>>> basically uses a DHT (openDHT) as a transport to then negotiate an
>>> encrypted SIP session for audio/video calls. Text messages are currently
>>> just sent encrypted over the DHT directly (no SIP negotiation). So a
>>> good protocol name is probably something like "Ring-dht", I suppose.
>>>
>>> Telepathy-ring is already taken, and the telepathy spec also warns
>>> against naming the CM the same as the protocol:
>>> https://telepathy.freedesktop.org/spec/Connection_Manager.html#Simple-Type:Connection_Manager_Name
>>>
>>> Some proposed pun names from the #ring IRC so far:
>>> telepathy-bell
>>> telepathy-hoop
>>> telepathy-single-ladies
>>> telepathy-doughnut
>>> telepathy-lord_of_the
>>> telepathy-o
>>> telepathy-my-precious
>>>
>>> Does anyone else have any good suggestions for either the name of the CM
>>> and/or the protocol?
>>>
>>
>>
>> I think the spec needs to be clarified
>>
>> In this case, Savoir Faire Linux produces both the protocol and
>> implementation using the same name.
>>
>> Therefore, I think that the spec should say something like: "it is OK to
>> name the CM after the implementation if the implementation and protocol
>> have the same name, preferably adding some vendor label to distinguish
>> possible forks"
>>
>> E.g. you could call it telepathy-opendht-sfl
> 
> No, I disagree with that. The spec is correct saying what it's saying.
> 
> #1 CM should not be named after the protocol because that can lead to
> confusion if there is another CM for the same protocol. And the fact
> that you distinguish it with the name of the company (sfl) is a bad
> idea, because it will discourage people outside that company as well as
> other companies from contributing to it and will also probably encourage
> forking in case the company becomes less active at some point. Imagine
> for example what you would think of telepathy-gabble if it was named
> telepathy-xmpp-collabora...
> 
> #2 CM should not be named after the implementation because that can also
> lead to confusion between the two projects (the telepathy CM and the
> implementation software). See the example of telepathy-sofiasip that
> became telepathy-rakia (mentioned in the spec as well). This is also a
> factor against telepathy-ring (or telepathy-ring.cx perhaps) because
> ring.cx is another software. You don't want users to think that this
> telepathy CM is somehow part of ring.cx or it can be used to talk to
> people only if they are using ring.cx on the other side. Maybe another
> implementation will pop up in the future and then ring.cx will be
> irrelevant as a name.
> 

This is not so clear cut.

I chose the name telepathy-resiprocate for the resiprocate-based CM
because telepathy-resiprocate is maintained in the reSIProcate repository:

https://github.com/resiprocate/resiprocate/tree/master/apps/telepathy

Maybe an exception should be made so that when a CM is officially part
of a protocol implementation (reSIProcate is a SIP implementation), then
it can use the name of the implementation.

> And let me add to that that names such as telepathy-opendht-sfl are
> ugly, because they are hard to pronounce. Quoting the spec, "The
> Telepathy project traditionally uses some sort of pun", which is what we
> should do for future CMs too.
> 
> In this case I think telepathy-bell is a great name, actually. It is a
> pun for "ring", yet it does not relate to it in a strong way.
> Additionally, it relates to OpenDHT as much as "ring" does (i.e. not at
> all).
> 


I'm OK with that choice too.