[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 #14 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-08-18 03:39:45 PDT ---
I think RequestHandlesByVCardField should probably be
RequestContactsByVCardField (rationale: doesn't work for rooms), and either
return a dict of (held handle, identifier) pairs, or even have
GetContactAttributes-like behaviour.

(In reply to comment #13)
> I don't think there is an identity between standard vCard field names and URI
> schemes.

Indeed, there is not an identity. The URL vCard field can hold any URI, though,
so in principle we could additionally add:

Protocol.AddressableURISchemes: as
    In addition to the AddressableVCardFields, the "url" vCard field is
    also addressable, if the URI scheme (the part before the ":")
    is in this list.

    For instance, if this is ["sip", "tel"], then you can call
    Connection.RequestHandlesByVCardField("url",
        ["sip:12345 at example.com", "tel:+441223362967"])
    and expect it to work, but
    Connection.RequestHandlesByVCardField("url", ["xmpp:bob at example.com"])
    will not work.

I don't think "url" is useful without qualifying it by schemes in any case, so
this seems harmless and useful.

> > I think the real power in URIs are in their query strings (subscribe, message,
> > etc.). So maybe the "noun" URIs should use the same API as vCard, and then
> > there would be a Connection method HandleURI or something that would execute a
> > URI with a query string.

In the web architecture, URIs are meant to be noun phrases ("Simon's e-mail
address", "Simon's XMPP account"), not verb phrases ("send Simon an e-mail") -
see <http://labs.apache.org/webarch/uri/rfc/rfc3986.html#identification>.
mailto: URIs are mis-named for historical reasons: given a mailto: URI for my
e-mail address, it's just as valid to add me to your address book as it is to
send me e-mail right now.

Many URI schemes extend this with parameters that can turn it into a verb, but
like you say, RequestHandlesByVCardField should be for the more generic use,
i.e. it should ignore those parameters.

> > For example:
> > HandleURI("xmpp:romeo at montague.net?message;body=Hello%20World")
> > would be the equivalent of Conn.I.EnsureChannel and Chan.T.Text.Send.
> 
> I think it's a good idea.

Can we spin this off into a separate bug with lower priority? This seems likely
to get much more complicated; I can see several issues straight away.

I'm not at all sure that the Connection is the right place to parse these
verb-like URIs. If you're passing one to a Connection, you've already decided
which Account it will act on, which is a non-trivial decision, and you've
already put that Account online, which is also a non-trivial decision.

We need to be a bit careful about who handles the channel, if there is one.
Perhaps it would be reasonable to say that acting on verb-like URIs is always
"ensure and forget" (the default handler is invoked, and the caller is only
told that it succeeded), and if you want to go beyond that you'll have to parse
it yourself.

I don't think it's appropriate for clicking on a URI in a browser to take an
irrevocable action (e.g. send messages). On the web there's an expectation that
links to URIs will be GET-like, rather than POST-like. For the XMPP ?message
parameter I think the functionality we actually want is "open a text chat, put
the given message in the edit box ready to send, *but don't send it*"
(analogous to a GET http link that takes you to a pre-composed draft webmail
message). We don't currently have a way for a CM to do that (but wjt has
proposed a way for a cooperating channel-request and Handler to do that, which
I think may be more appropriate anyway).

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