[Bug 26866] add support for requesting handles for a vCard field or URI

[bugzilla-daemon at freedesktop.org]

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

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Status Whiteboard|                            |review-, not suitable as
                   |                            |draft yet

--- Comment #42 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-09-03 03:22:07 PDT ---
This branch adds stable (i.e. guaranteed) API, so it can't easily be merged as
a draft. I think it'd be worth moving TargetURI, TargetURIScheme,
TargetVCardField and TargetVCardAddress to a new Chan.I.Addressing which can be
merged as a draft (we can consider flattening them into Channel in Telepathy
1.0), and moving the Protocol stuff to a Protocol.I.Addressing (ditto).

Alternatively, if you feel strongly that the new stuff should be a core part of
Telepathy as soon as it's undrafted, put it on Channel.FUTURE and
Protocol.FUTURE pseudo-interfaces.

TargetURIScheme exactly duplicates part of TargetURI, so it deserves a
<tp:rationale> explaining that yes, it really is duplicate information, and it
exists to be available in requestable channel classes. TargetURI and
TargetURIScheme should probably reference each other (or perhaps only in one
direction) to say that TargetURI MUST start with TargetURIScheme + ":".

Protocol.NormalizeVCardAddress should document what happens if the VCard_Field
is not in AddressableVCardFields, and what happens if the VCard_Address is not
a syntactically valid instance of that vCard field.

(My opinion: InvalidArgument or NotImplemented for the former, InvalidHandle
(stretching its meaning rather) or InvalidArgument for the latter.)

Likewise for NormalizeURI.

NormalizeURI seems to have incorrect argument names/types, referring to vCard
addresses.

> +          The URI to normalize. The URI's scheme must appear in

It might be worth repeating "scheme (i.e. the part before the first colon)"
here?

The copyright notice in Chan.I.Addressing needs stretching to include 2010.

> +          The URI addresses to get contact handles for. The URI
> +          schemes need to be supported by the connection, this could
> +          be determined by inspecting the TargetURIScheme
> +          fixed-property on
> +          [...]Requests.RequestableChannelClasses</tp:dbus-ref>.

No, I think this should be from the Protocol: the requestable channel classes
are unnecessarily strict. A telepathy-sofiasip instance whose server lacks a
PSTN gateway can still discuss, and allocate handles for, tel: URIs, even if it
can't actually call them.

/requested-address and /requested-uri need well-defined semantics (I propose
"MUST be omitted from the mapping") when not requested via the relevant method.

> If the <code>URL</code> vCard
> +          field is addressable, a colon, followed by the supported URI
> +          schemes will be concatenated.</p>
> +
> +          <p>For example: <code>["tel", "x-sip", "url:tel", [...]

I thought we agreed this was a bad idea? If so, please eradicate this mention
of "url:"-prefixed pseudo-fields, and replace it with something like:

    The <code>url</code> vCard field MUST NOT appear here; see
    _AddressableURISchemes_ instead.

    | In practice, protocols have a limited set of URI schemes that make
    | sense to resolve as a contact.

GetContactsByVCardAddress and TargetVCardField should probably gain a similar
note, pointing users to the appropriate URI-based alternative.

> Do you think using a url: prefix is a bad idea everywhere we expect a vcard
> field? Or just that we should use uri: instead?

For the record: if we'd gone this way, "uri" would be bad, since the vCard
field name is "URL" with an L.

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