[Telepathy] On removing/standardizing .profiles

[Andre Moreira Magalhaes]

On Mon, 2010-08-02 at 15:13 +0100, Simon McVittie wrote:
> 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".
> 
Agreed here, I believe we should just not define profiles for "vanilla
profiles". The gabble.profile file should define profiles for things
like google-talk, facebook, etc. But the high-level APIs in tp-qt4 or
tp-glib should expose Profile objects for "vanilla profiles", meaning
that it should fake Profile objects using the info found in the manager
file and Protocol iface.

This is useful so the accessor in Account would return a valid Profile
object even for accounts using the "vanilla profile".

Same for ProfileManager that should also include these fake Profiles.

> >   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).
I believe you have some points here, but I am not sure if we should have
this or not, so let's hold this and we can always add translations
later, by extending the file format if needed.

> > 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?
Mandatory means that for that service this field is mandatory, cannot be
empty, even if it's not mandatory by the CM itself.

Also XML attributes need a value, so either we add a child element
mandatory or have a mandatory=true attr there. false is default.

> >   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.)
> 
Editable means that for this service this param MUST be the one defined
in value and should not be user-editable. This is exactly what you said
about google talk server, that for accounts using the google talk
profile cannot edit the server field for example.

> >   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.
> 
Yes, invisible is the most common case here, but we may also find some
services that do not support other presence types, so I believe we
should be able to disable by presence type.

> >   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).
> 
We may have a alias element maybe. The name explains itself.

> >   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.
:P

> 
> >   <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.
> 
I chose to go to the route "this service do not allow these rccs"
instead of "it only supports this subset". I believe we should choose
one of them and stick to it. For facebook we would need to disable many
rccs, but for another server we should need to disable only one, so not
sure which one to choose.

Regarding allowed, I believe we should just omit it.

A format may be something like

<suppressed-requestable-channel-classes>
 <requestable-channel-class
channel-type="org.freedesktop.Telepathy.Channel.Type.RoomList">
  <properties>
   <property id="org.freedesktop.Telepathy.Channel.TargetHandleType"
dbus-type="u" value="2"/>
  </properties>
 </requestable-channel-class>
</suppressed-requestable-channel-classes>

BR,
Andrunko