On 30/10/12 14:40, Xavier Claessens wrote: > So I suggest CM should store on disk the full roster
Maybe... > in a format/location defined in the spec. I'm somewhat less happy about this: the natural way for a CM to store the contact list for its own use is either in whatever its native format is (for instance the roster XML for Gabble), or in a sqlite database or something. I don't think we really want to lock-in "the roster is stored in (XML|sqlite3) format at *this* location" as part of the Telepathy API. Even with the proposed Avatars redesign for 1.0, we've been able to avoid locking-in the specific location: all we lock-in is that there are files *somewhere* containing the avatars, and files of the same name + ".mime" containing the MIME-type. Straw-man alternative 1: access the cached roster via a D-Bus API on the Account, and have MC cache it (in a CM-neutral, MC-specific format, which means we don't have to duplicate the cache code in every CM). LastKnownRoster, defined as "the last known value that would have been returned by GetContactListAttributes([some set of interfaces], False)"? Straw-man alternative 2: access the stored roster via a D-Bus API on the ConnectionManager or Protocol, keyed by... I don't know what, actually. NormalizedName is almost what we want, except for in protocols where identifiers are non-namespaced, where it's worse than useless. IRC, AIM, Skype are the usual examples of non-namespaced identifiers, but AIM and Skype are proprietary single-implementation protocols, and IRC doesn't have contact lists. Do we know of any protocol that has contact lists but has multiple, non-federated servers with overlapping sets of "unique" identifiers? Maybe SILC? > Of course when folks read the disk DB, since account is offline, the DB > is immutable, so we don't need any fancy change notification. So the change notification needed is limited to "account is now online, reload from there"? I do like that idea - particularly if this is API on the Account, which would mean you're naturally monitoring the Account anyway. > This means we have to define persona and individual uid: > > * Persona uid: I suggest using N9 format: > "telepathy://<account path>/<contact-id>", > "eds://<ESource id>/<EContact id>". > Or anything from which we can fetch a TpContact or EContact. I remain opposed in principle to things that try to look like URIs but are neither IETF-registered nor universal :-P but I'm also (at least somewhat) pragmatic about them. If we're going to encode (account, contact) tuples in a thing-that-looks-like-a-URI, because / appears in account paths but : cannot, I would recommend something more like: telepathy:gabble/jabber/smcv_40example_2ecom:xavier%40example.com (or possibly with the /org/freedesktop/Telepathy or /im/telepathy1 part included, or with some other punctuation.) I wonder whether we actually need to encode the account, though. Would it be enough to publish the URI or URIs of each contact (xmpp:xav...@example.com) via our existing Conn.I.Addressing1, and identify personas by those? The fact that a contact can have more than one URI (e.g. xmpp:nnnnn...@messenger.live.com is also msnim:add?contact=al...@example.com) complicates matters, though. On IRC - always the complicating case for identifiers - we could just say "this protocol doesn't have permanent enough identifiers to publish URIs or link contacts", or use e.g. irc:s...@irc.oftc.net (complicating factor: irc:s...@irc.eu.oftc.net is equivalent, but without Freenode-specific knowledge, you can't know that). > * Individual uid: there are 2 cases, does it have just one Persona or more? > - just one: use its persona uid. > - more than one: use a uuid and keep it in the DB. Does this mean that if I have you as an XMPP contact, and then I add you to my Evolution address book, your Individual ID changes from telepathy:blahblah to urn:uuid:foobar? I don't think that that's desirable. > We need change notification when that DB is changed. Probably something like > dconf where a daemon does the writing and clients does direct reading. Perhaps. > Maybe > crazy idea but could we actually use dconf for this? I'm pretty sure this is not configuration and should not live in dconf. We could perhaps use gvdb (the "GVariant database" that is dconf's binary format), though. S _______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy