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. Regards, Rob -- Robert McQueen +44 7876 562 564 Director, Collabora Ltd. http://www.collabora.co.uk _______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
