On 09/30/2013 07:56 PM, Simon McVittie wrote:
[...]
Am I right in thinking that the closest equivalent if using
ChannelDispatcher instead of Account would be something like this?
- delete ChannelRequest.Succeeded(), CR.Failed(s, s), CR.Proceed()
- add ChannelDispatcher.RequestSucceeded(o), CD.RequestFailed(o, s, s)
(where the object paths are the path of the CR and the other arguments
are carried over)
Yes, though you don't have to remove the signals and method from the
ChannelRequest interface (unless you really want to avoid duplicate code
paths).
This is somehow similar to the case of AccountManager.AccountRemoved and
Account.Removed signals, where you have the signal emitted from the
parent object as well, to offer different levels of information detail
(clients who need to use the account will listen to Account signals, but
those you don't can be content with AccountManager.AccountRemoved).
Here's another two possibilities to shorten the round trip (with
different levels of evilness :-) ):
1) Use the same API that you have in spec-next, but let smart clients
know in advance what the CR object path will be, so that they can setup
the match rules and call Proceed() immediately after calling
CD.CreateChannel(). In practice, you could allow the client to specify a
"SuggestedUniqueName" property in the dictionary they pass to
CD.CreateChannel(), and compose the ChannelRequest object path like
"<documented-object-path-prefix>/<suggested-unique-name-value>" if this
results in an available object path (if not, return a different object
path).
Or even use
"<documented-object-path-prefix>/<client-bus-connection-name>-<channel-type>-<user-action-time>"
when available and do not require any additional input from the client.
2) Just forget about the ChannelRequest object, and let
CD.CreateChannel() return a D-Bus error on failure, or the new channel
(as currently done by the CR.Succeeded signal) as return value. It just
needs to be documented that this call might take a long time, so setting
a longer D-Bus timeout is recommended. Cancellation could be implemented
as a separate method on the CD, and it could either take the same
dictionary of requested properties that was passed to CreateChannel, or
a single string that identifies the request (which could have been
previously passed to CreateChannel by the client, or computed based on
the client connection name, channel type and user action time, like in
the point above).
This would also have the minor advantage that it would be harder for a
client to cancel a request made by another client (unless they willingly
talk to each other and share the CR details).
If so: cost:
- no way to tell a CR has been invalidated without watching the CD's
signals (valid, but somewhat odd)
- anything that is interested in *any* CR is woken up by signals for
*every* CR (it can't use arg0path, because that'd require bringing
back Proceed() to avoid the same race condition)
Right, but as you said below, the latter drawback can be reduced if the
clients only subscribe to the CR signals when needed; and besides, in
the typical case where we really care about the performance down to the
millisecond, we probably won't have more than 2 clients running at the
same time.
[...]
One alternative design would be to require that the requesting client is
a Client (probably requiring it to pass its bus name to the
Create/Ensure call), and call something analogous to RemoveFailedRequest
on it instead of using signals.
It might make the development of simpler clients a bit more complicated,
but it would indeed address the issue.
On a side note: would it be possible to move telepathy to its own bus,
(so that it could be given higher/lower priority depending on the device
profile) or would that require changes to the spec?
It would be possible, but I'm very cautious about introducing parallel
buses, because as soon as you have parallel buses, you get undefined
message ordering, and lose atomicity of name ownership etc. (e.g.
Empathy would own a Client name on the Telepathy bus, and a GApplication
name on the session bus).
Right, though it could be solved if the client was a bit careful. Like:
- if owning the GApplication name fails -> quit
- if owning the Client name fails -> retry
Apart from the clients, do you think that the ChannelDispatcher,
AccountManager and the connection managers would need some deeper
changes to cope with living in a bus which is not the session bus, or
could it safely work with just minor changes?
If the latter, there might be some value in trying to get them to be
bus-agnostic, even though in practice it might turn out that the feature
is never used.
(so, if someone really wanted to put telepathy in a separate but, he
would "only" need to care about the clients)
[...]
Similar to the other thing, I'd like to see something more quantifiable
than "it might hypothetically be a problem" before adding complexity.
Absolutely. I wrote this because I think that the D-Bus server was
rather inefficient with message dispatching when many clients were
connected (maybe it was linearly going through all the match rules
installed), but now I don't even remember if I actually checked this or
just imagined it. :-)
Based on my experience with maintaining libdbus (and in particular, the
undocumented mess that is dbus-launch), if we do have a separate
Telepathy bus, I'd like to define a single way to locate it (probably
"ask a trivial session-bus service on startup"), and heavily discourage
any alternatives. Definitely no tricks with X11 windows or environment
variables...
Right, and I think that the most reasonable place for this trivial
session-bus service would still be inside MC, since the typical
telepathy client will talk to it shortly afterwards.
Ciao,
Alberto
_______________________________________________
telepathy mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/telepathy
