[Bug 24898] replace or remove MC 5's Account.Interface.Compat.SecondaryVCardFields

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=24898

--- Comment #8 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-10-25 05:24:24 PDT ---
Spec:

> +    <tp:added version="0.21.3">(draft 1)</tp:added>

0.21.UNRELEASED please; you're assuming that this'll be merged as a draft
before the next spec release, which isn't necessarily true.

> +      <p>The Compat interface holds properties necessary for maintaining the
> +        libmissioncontrol compatible layer.</p>

This isn't the Compat interface, and "remain compatible with libmissioncontrol"
isn't the reason for this functionality. Why did libmissioncontrol have it? You
may be able to derive some useful wording from the Conn.I.Addressing interface.

Something like this, perhaps:

    Some accounts can be used for multiple protocols; for instance, SIP
    and Skype accounts can often be used to contact the PSTN, MSN and
    Yahoo accounts can contact each other, and XMPP accounts can potentially
    contact many protocols via a transport.

    However, if the user does not intend to make use of this functionality,
    user interfaces can improve clarity by not displaying it: for instance,
    if a user prefers to call phone numbers via a particular SIP account,
    when an address book displays a contact with a phone number, it is
    desirable to display a "call with SIP" button for that account, but
    avoid displaying similar buttons for any other configured SIP or
    Skype accounts.

I'd assumed that this interface would have parallel API for vCard fields and
for URI schemes, like Conn.I.Addressing does, but I can see that that raises
the possibility that they get out of sync: if my account has UseForFields = []
and UseForSchemes = ['tel'], a vCard-field-based UI would not offer it for
telephony, but a URI-scheme-based UI would.

If you have any thoughts on whether vCard fields, URI schemes, or both make
most sense, I'd like to hear them!

> +        <p>A list of fields indicating the type of URI addressing scheme
> +          the the account can be used for (eg 'tel') indicating the
> +          account is suitable for use by apps offering a telephony UI,
> +          or 'sip' or 'xmpp' for those protocols</p>

Please make it clearer that this is a matter of user preference rather than
technical capability - every Skype account can potentially contact the PSTN,
but it's up to the user whether they want to use it as such or not.

> +      <arg name="Old_URI_Association" direction="out" type="b">
> +        <tp:docstring><p>The old URI association value</p></tp:docstring>
> +      </arg>

We don't normally do this. Is there a special reason to do so?

> +      <arg name="Association" direction="in" type="b">
> +        <tp:docstring>
> +          <p>Whether to associate or disassociate with/from the URI scheme</p>
> +        </tp:docstring>
> +      </arg>

I prefer wording of the form "True if this account should be offered as a
possible way to contact this URI scheme; False if it should not".

-----------------------------------------------

MC:

Your branch seems to be against telepathy-mission-control-5.6, which seems
rather inappropriate for a new feature.

> +  <interface name="org.freedesktop.Telepathy.Account.Interface.Addressing">

You need a .DRAFT in there (and the draft used in a trial implementation should
generally be byte-for-byte identical to your latest spec proposal). I haven't
reviewed the implementation in detail.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.