[Telepathy] New ContactInfo interface based on vCards
robert.mcqueen at collabora.co.uk
Thu Dec 4 13:07:18 PST 2008
Dafydd Harries wrote:
>>>> While vCard
>>>> is kind of hairy and suboptimal, it's widely used (both XEPs relating to
>>>> contact info are based on vCard) and there's no point in defining
>>>> another format only to have to map to and from the vCard semantics in
>>>> every CM.
>>> If vCards are widely used, perhaps sending and receiving them as strings is
>>> not such a bad thing. Otherwise software that already supports them has to
>>> be modified to support our new interface, or has to undo the translation that
>>> the connection manager does. Essentially, we *have* defined another format,
>>> it's just not a text one, and software will have to do lots of mapping back
>>> and forth.
>> I believe the idea was to avoid requiring every connection manager
>> to be able to compose and parse arbitrary vCards; with a structured D-Bus API,
>> the CMs have to be able to map their own semantics to vCard, but they don't
>> have to understand the syntax.
> But if most connection managers are just passing through vCard data, then it's
> less work overall. It's just that Gabble would have to grow code to convert
> bizzaro XML vCards to text vCArds.
I don't think "most" protocols use literal text vCards however. They all
seem to have their own kinds of syntax which are subsets or vcard-ish.
But more generally, vCard's serialisation and syntax is pretty icky
(especially before v3.0 where UTF-8 was mandated, meaning 2.x vCards
wouldn't be valid strings on D-Bus), but the data model is... passable.
I don't like the idea of forcing eg the IRC CM to render WHOIS data into
a vCard string, or the AIM connection manager to turn its blob of HTML
into a vCard string, but populating a reasonably coherent D-Bus data
structure with the information seems less onerous.
Robert McQueen +44 7876 562 564
Director, Collabora Ltd. http://www.collabora.co.uk
More information about the Telepathy