Hello world, Simon, Sjoerd and I went over a bunch of bugs and proposed additions to the Telepathy spec today. Non-trivial topics:
• Server messages on Facebook Chat don't make it to the UI for two reasons; • Protocol objects; • Better feedback from setting RequestedPresence; • Anonymity (aka hiding your caller ID); • Mute; • Cellular-specific properties on Connection. == Trivia == • clarifying when MessageSent should be emitted <http://bugs.freedesktop.org/show_bug.cgi?id=27282>: yes • labelling message parts which are thumbnails <http://bugs.freedesktop.org/show_bug.cgi?id=27262>: yes, but also specify that 'alternative' shares a namespace with 'identifier'. • Use handler capability tokens to indicate support for audio and/or video on Call, rather than needing three handler filters <http://bugs.freedesktop.org/show_bug.cgi?id=27335>: yes. · Later, Sjoerd noticed that this means that to express "I support 1-1 video calls, but only audio in multi-party calls" you need two handler heads. But this is an edge case, and you can't express this at the XMPP caps level either. == Server messages on facebook == <http://bugs.freedesktop.org/show_bug.cgi?id=26696>: Message from Facebook Chat when it disconnects you for signing in from a new location doesn't reach the UI First problem: Gabble doesn't think chat.facebook.com is a valid handle. • Should Gabble let you request a handle for JIDs with no node part? If so, then if you mistakenly try to contact 'will.thompson' rather than '[email protected]', the failure will occur much later than it currently does (since at the moment Gabble won't give you a handle, or a channel, for the former). • Idle is a bit more tolerant of contact IDs it receives from the network than those it receives over D-Bus, because bip uses a nickname that's illegal per the IRC RFC. This would be an acceptable stop-gap solution in Gabble, too. Second problem: what do we do about channels appearing as the connection closes? • this could be a property of the disconnecting state in hypothetical Telepathy 1.0? • add a flag for "i'm well behaved, i'll close up my own channels" · problem: then you have to ack all the messages before you can reconnect · here's a bad idea: uniquify channel paths across connections, make channel outlive connection. rejected: you need the connection to look up aliases and do other useful things with a channel. · here's another bad idea: re-use connections, rather than having them die when they become Disconnected. • we punted on this for now. == Protocol objects == <http://bugs.freedesktop.org/show_bug.cgi?id=20774> Implementation details: • the tp-glib implementation involves subclassing TpBaseProtocol. it supports CMs like haze which discover their own protocols at run-time, as well as CMs that have one or two staticly-determined protocols. IdentifyAccount: • This makes it possible for MC's account path to be sensible, and be the same if you delete and re-create account so that your old logs match up. • Also solves the problem where you can create two accounts for the same JID and then can't actually connect them both at once, as Siraj mentioned on #telepathy today. • We could add an "IRC Network" parameter which Idle ignores but uses to generate responses to this? This would mean that if you switch between two servers on the OFTC network, the account path could still be w...@oftc or something. NormalizeContact: • Needs explanation of why it's best-effort only, with reference to XMPP where [email protected]/bong.hits would be normalized to [email protected] by this method even though that's wrong. • Why might it raise NotImplemented? Salut. Guaranteed vs. Possible {Interfaces,ChannelClasses}: • Why would you ever care about anything other than the union? • Should we distinguish between channel classes that every contact will have, channel classes that some contacts may have, and channel classes that the whole connection might not even have when you sign in? · Again, what would the UI do differently in each case? • Possible route: just have one list for each, we can reintroduce Guaranteed later if needed. Agreed that presets such as settings for well-known SIP providers, Google Talk, Ovi etc. don't live here; they should live outside the CM, so that you can install extra files to describe (e.g.) your company's SIP or XMPP service. VCardField: · as a first step, if you have a vCard and it's got an x-jabber field and you want to know how you can contact this person, you can just go through your protocols and find them. · this is stolen directly from MC's profiles as used on Maemo 5, and is valuable there. · this is not for getting a contact out of a protocol and turning it into a vCard field, because a protocol might support several. Example: SIP supports tel and sip. this use case is further work. · nitpick, explain what "telephony" means, exactly: it's Ye Olde POTS, not IP Telephony. DisplayName: · This is a really overloaded name; can we call it EnglishName? Icon: · "system's icon theme" is a bit of a cop-out. can we say xdg icon spec names? Protocol.Interface.Presence: · Maybe guaranteed vs. possible makes sense here? · Counter-argument: what's the UI meant to do if you say "you might be able to be invisible? i don't really know?" · Will reckons we should just make Gabble support invisible everywhere which removes the one case where possible ≠ guaranteed Sidecars we'll ignore for now; the rest seems fine. == Setting a not supported presence state to a Telepathy == == account does not deliver any failing feedback. == <http://bugs.freedesktop.org/show_bug.cgi?id=26752> Simon wants a RequestPresence(...) method, which: • Sets RequestedPresence accordingly; • Waits while the account signs in; • Ultimately returns one of: · success, · i had to fall back to this other presence, or · bzzt, network error. Here's a possible use case: · Foo is a presence tray icon · Bar is a demo application that just tries to sign in an account as 'dnd' · Bar tells my account to sign in as 'dnd'; Foo starts blinking because RequestedPresence changed from 'offline' to 'dnd' · The account signs in, as 'available' because the protocol doesn't actually support 'dnd'. When should Foo stop blinking? Answer: when the ActualPresence changes. Transitions of RequestedPresence away from values other than 'offline' shouldn't make the tray icon blink: apart from when you're signing in, presence indicators should display ActualPresence. We think that the use case in the bug would be solved by the RequestedPresence() method described above. == Anonymity == <http://bugs.freedesktop.org/show_bug.cgi?id=24909> Connection interface: • SupportedAnonymityModes should be documented to only be stable once you've connected. Should x-ref the type. • Should SetAM just be a writeable D-Bus property? Maybe not if it involves talking to the sky on GSM. But it needs to be a writeable D-Bus so that it can be a connection parameter which is also a D-Bus property using the DBus_Property Conn_Mgr_Param_Flag, allowing Mission Control to update it on the fly when you change the corresponding Account's parameters. • Will wonders if this interface might be overly tinfoil hatty and support features no-one will ever use, and maybe we should just have a HideCallerID: b property? · Others think that supporting these other flags is fine, but we should order the flags by how obscure they are, so that the one you actually care about — OriginatorInfo, aka caller-id — is first, and then the introduction can say "If you just care about hiding your caller ID, call Set("Flags", 1)". • Capitalization is wrong. smcv or similar needs to do an editorial pass-through. Channel interface: • Properties don't need to be Initial*, they're immutable. Should be AnonymityModes, AnonymityMandatory • Should say that those two are requestable. • AnonymizedDisplayName: this isn't a display name, it's an Identifier. Say that it's not requestable. == Mute == <http://bugs.freedesktop.org/show_bug.cgi?id=26807> Do we need to tell Farsight to mute things, or just leave it up to the UI? AP: speak to Olivier about this. (Also, can we make Hold easier in Call?) Do we want to relay the fact that we've muted our mic to the other parties? We don't see any harm in it: it's useful metadata, and isn't an information leak because you can hear that someone's gone silent anyway. If we make the UI control the actual muting (or in the Maemo case, make it talk to s-e directly) then it could control whether not to tell the other guy by whether or not it call Mute() on the CM. But for GSM it needs to call Mute() on the CM because that's the thing which cares. So two semantics here: one informational, one a request. == Cellular == <http://bugs.freedesktop.org/show_bug.cgi?id=24910> This looks fine, we should ship it. Regards, -- Will _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
