[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

--- Comment #23 from Eitan Isaacson <eitan.isaacson at collabora.co.uk> 2010-08-25 13:07:31 PDT ---
(In reply to comment #17)
> If we imagine that our server has some way to tell us its capabilities, we
> could reasonably exclude the telephony-related requestable channel classes on
> servers that lack PSTN connectivity, but there seems no reason not to let
> people request handles for such identifiers? The handle will represent a string
> like tel:123456, which is a perfectly valid thing to talk about, even if our
> particular connection has no way to communicate with it. All the contact
> attributes will have dummy/unknown values, but that's not harmful.
> 

So, let people retrieve meaningless contacts but fail if they try to
communicate with them? Sounds reasonable.
Maybe Addressing/representations (see below), is an empty mapping the UI could
assume the contact is not reachable.

> RequestContactsByVCardField should be named with Get: "RequestThing" has a
> network round-trip before completing, whereas "GetThing" returns whatever
> cached values are available.
> 
> > +          <p>Attributes from the interface
> > +            <tp:dbus-ref>org.freedesktop.Telepathy.Connection</tp:dbus-ref>
> > +            and
> > +            <tp:dbus-ref>org.freedesktop.Telepathy.Connection.Interface.ContactInfo</tp:dbus-ref>
> > +            are always returned, and need not be requested
> > +            explicitly.</p>
> 
> I can see what you're trying to do here, but I don't think it's appropriate.
> ContactInfo is information that the contact *claims* is true, but the
> interpretation of the contact's identifier as a vCard field is unarguably true,
> can be parsed by the CM without any networking, and can't change.
> 
> I think it'd be better to have Addressing implicitly-requested, and have an
> attribute on Addressing that gives the interpretation of the contact's
> identifier in terms of vCard fields. However, that itself opens a can of worms,
> because there can be more than one interpretation, so we'd have to have
> something like this (for the JID smcv at example.com):
> 
> Addressing/representations = (
>     ["x-jabber": "smcv at example.com"],
>     ["url": "xmpp:smcv at example.com"],
>     )
> 
> A subtlety is that if the contact identifier wasn't given in a normalized form,
> the requester needs some way to relate it back to what they asked for, which
> you don't provide here. Perhaps if I asked for the x-jabber contact
> smcv at EXAMPLE.COM, I should get back:
> 
> Addressing/representations = (
>     ["x-jabber": "smcv at example.com"],
>     ["url": "xmpp:smcv at example.com"],
>     )
> Addressing/before-normalizing = (
>     ["x-jabber": "smcv at EXAMPLE.COM"],
>     )
> 

Mapping back contacts to the actual request could also be done by their index
in the returned list, if we promise the list will be the same length as the
requested addresses list. That is obviously not good enough, because the client
probably disposed the request list in the meantime.

How about something like this... For example on Gabble (with no PSTN gateway):

Addressing.GetContactsByVCardField("x-jabber", "eitan at EXAMPLE.COM", []) =>
Addressing/representations = {"x-jabber": "eitan at example.com",
                              "url": "xmpp:eitan at example.com"}
Addressing/requested = ("x-jabber", "eitan at EXAMPLE.COM")

And for a TEL request:
Addressing.GetContactsByVCardField("tel", "+12065553232", []) =>
Addressing/representations = []
Addressing/requested = ("tel", "+12065553232")

> For the second case, requesting channels, we should just advocate setting the
> TargetVCardField and TargetVCardAddress directly.
> 
> > The one issue I see is the addition of Protocol.AddressableURISchemes being
> > partial: It has no change notification, and it does not have a
> > channel property to make it useful with RCC. So we are left with the
> > URI scheme support being static and not discoverable when online.
> 
> There's nothing to stop you using Protocol for an online connection;
> TpConnection can grow convenience API for this if needed. I see your point
> about it being a static superset, though.
> 

The static superset was my only point.

> Perhaps we should special-case "url" in TargetVCardField, or maybe even in
> AddressableVCardFields too (which would remove the need for
> AddressableURISchemes), so you set (TargetVCardField, TargetVCardAddress) to
> either ("url:xmpp", "xmpp:smcv at example.com") or ("url:xmpp",
> "smcv at example.com")?

I like it.

> 
> (If we go for the former, duplicative, form, telepathy-glib's channel manager
> code could enforce it if desired. If we go for the latter form, then
> hierarchical URI schemes would look pretty weird: ("url:http",
> "//people.collabora.co.uk/~smcv/") :-)
> 

tp-glib could enforce either, no? Just strip/add scheme. Let's go with the
former.

> Details
> =======
> 

I'll get to those, and report back.

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