[Telepathy] On removing/standardizing .profiles

[Simon McVittie]

On Mon, 02 Aug 2010 at 03:04:54 -0300, Andre Moreira Magalhaes wrote:
>   All CMs should ideally install a profile named $cmname.profile that
> will contains the default profiles for that given CM.

One of the goals for this work has been that the "vanilla profile" doesn't
need to exist. This is very useful if you're telepathy-haze, which can randomly
grow support for new protocols at runtime (via prpl plugins).

(By "vanilla profile" I mean things like irc, jabber and sip, as opposed to
freenode, google-talk or ekiga-net. Proprietary protocols will generally
*only* have a "vanilla profile", because the provider and the protocol are
synonymous.)

In the spec 0.18 cycle, we made it unnecessary for Haze to install .manager
files; forcing it to install profiles seems like a regression.

Manager files and Protocol D-Bus interfaces should also contain enough
information to synthesize a "vanilla profile".

>   We should support i18n of fields such as supported presences and
> parameters defined in profiles. As CM parameters names are not defined
> in the spec we should be able to add proper translations for parameters.

(As a shorthand for multiple platforms I'm saying "GNOME and KDE" here, but
the same things apply to GNOME vs. KDE vs. LXDE vs. XFCE vs. whatever.)

Our position so far has been that translation is a job for UIs. In practice,
you can't make a high-quality account creation UI without a minimal level of
protocol-specific knowledge (Empathy has protocol-specific UIs for all our
well-supported protocols), and UIs have better translation infrastructure than
us anyway (e.g. Empathy is supported by the GNOME translation team, I assume
KDE has something similar).

Having Telepathy translations also means that if the GNOME and KDE translators
use a different translation for a particular English term, we have to pick one
and have users of the other platform complain, whereas if Empathy and Kopete
do the translation, Empathy will be consistent with all other GNOME apps and
Kopete will be consistent with other KDE apps (which I think is likely to be
more important than Empathy and Kopete being consistent with each other).

Making a sketchy auto-generated UI is of course possible (Empathy does this
for all protocols where it doesn't have a specific UI), but it's sufficiently
sketchy already that translating it isn't necessarily very important - it's
more a developer/bleeding-edge-user convenience than something suitable for
end users.

Do KDE people plan to have more than one account creation UI in the
platform? It seems like one of the bits of Telepathy that ought to be
one-per-UI-platform (e.g. in GNOME, the account creation UI should be Empathy,
unless someone moves it to the settings menu or something, in which case it
should be removed from Empathy altogether).

I'm not saying that Telepathy should have one UI per platform, just that
account creation/editing probably should. There are things other than account
creation where having more than one in a platform might well make sense,
like presence choice (GNOME panel vs. Empathy, Kopete vs. a plasmoid or
something).

> The idea here is to add a
> "label" child element that contains a "lang" attribute for all possible
> fields that can be translated.

If we're doing localization in XML, please use xml:lang (as seen in XMPP),
which is part of the core vocabulary of XML :-)

>   Profiles must be able to define a value for a parameter and whether
> this parameter is mandatory or should be disabled for a given service. 
>   The "parameter" element should support a boolean attribute "mandatory"
> for mandatory parameters and a attribute "value" to define the default
> value. For example:

What does mandatory="false" mean? When would you use it?

>   Maybe we should add a boolean attribute "editable" to indicate whether
> the parameter is editable for this service or must be the same indicated
> by the "value" attribute.

How does editable differ from the inverse of mandatory?

(One use-case for editable="false" is the Google Talk 'server'. One use-case
for editable="true" is that in a Freenode profile, the server field could
default to irc.freenode.net, but be editable in case you want to use
irc.eu.freenode.net instead.)

>   Some services do not support all presence types defined in the spec,
> so we should indicate whether some presences are known to not be
> supported.

I believe XMPP (invisible not always working) is the only major use-case
for this? Recent work on supporting more versions of invisibility in Gabble
means this is much less important.

>   Presences not defined by the spec should be ignored.

Careful. Protocols can define statuses with protocol-specific names, as long
as they have a Connection_Presence_Type defined by the spec: for instance,
MSN could have "on-the-phone", of type Connection_Presence_Type_Busy (but
it's not acceptable to select "on-the-phone" if the user chooses Busy from a
menu).

>   To do this we should add a "supressed-requestable-channel-classes"
> element that contains child elements "item" for all RCCs not supported.
> The syntax of the "item" element value should be the same used to define
> RCCs in manager files (See Protocol).

XML containing parsed text considered harmful! If you want to re-use
serializations from Protocol, use a keyfile (.desktop format); if you want to
use XML, use XML.

>   <suppressed-requestable-channel-classes>
>    <item>
>     org.freedesktop.Telepathy.Channel.ChannelType
> s=org.freedesktop.Telepathy.Channel.Type.RoomList
>     org.freedesktop.Telepathy.Channel.TargetHandleType u=2
> 
> allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy.Channel.TargetID;
>    </item>
>   </suppressed-requestable-channel-classes>

This seems rather speculatively general to me. Including 'allowed' here also
makes it very fragile: if we add RoomID (from Jonny's Room interface) to
the allowed MUC properties in Gabble, a third-party Facebook profile would
fail to suppress the MUC RCC.

As far as I understand it, we basically have two situations now:

* everything that the CM supports will work, perhaps with a couple of
  exceptions (Google Talk is full XMPP, except that their vCards don't support
  a lot of fields - but that's not information you need while offline anyway)

* almost nothing that the CM supports will actually work (Facebook can't
  do MUCs, but it can't do calls or file transfers or Tubes or setting your
  own avatar or manipulating your contact list, either)

Would it be sufficient for the Facebook RCCs if we had a way to say "of the
things the server supports, only these handle type / channel type pairs can
be expected to work"?

If we encounter a server that supports *almost* everything the CM does,
we might later need to add "these few specific things don't work". I suspect
those cover every situation we're likely to encounter in practice.

Regards,
    Simon