[Bug 24120] Refactor the McdDispatcher

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=24120





--- Comment #37 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2009-10-27 10:21:19 PST ---
(In reply to comment #36)
> Up to 92d18cf0d4:
> 
> dr4.6 looks fine.

May I merge dr4.5 and dr4.6, on the basis that your criticisms of dr4.5 were
all fixed in dr4.7?

> In get_connection:
> 
> +        _mcd_dispatch_operation_get_connection_path
> +            (MCD_DISPATCH_OPERATION (self)));
> 
> Opening paren should be on the same line as the function name.

Appended to dr4.7

> +    /* collect object paths into a hash table, to drop duplicates */
> +    for (c = channels; c != NULL; c = c->next)
> +    {
> +        const GList *reqs = _mcd_channel_get_satisfied_requests (c->data);
> +
> 
> Why would there be duplicate satisfied requests?

Pre-existing problem, I just moved the code. I *believe* that there should
never be duplicates, because each request is satisfied by at most one channel -
but beware that McdChannel is sometimes a Channel and sometimes a
ChannelRequest, so it's non-obvious.

When I refactor MC so McdChannel doesn't exist (long-term goal), this can
probably start asserting. For now, may I "resolve" this by filing a bug, and
adding a FIXME comment referencing it?

> Out of interest, what was the rationale for the spec saying:
> 
> > If the same NewChannels signal announces some channels that match the filter, and some that do not, then only a subset of the channels (those that do match the filter) are passed to [ObserveChannels].
> 
> It makes the code in MC a bit less straightforward than it would be otherwise,
> and well-behaved observers still have to deal if MC gives them channels they
> don't understand.

A good point. We should perhaps reverse that, either in 0.19.x or when we break
D-Bus API (depending how serious a change the spec cabal think it is).

The rationale was that the observer only asked to see certain channels, and
it's somewhat easy for MC to arrange for that to happen. You're right that a
well-behaved observer needs to cope with badness anyway, although I'm not sure
how many observers will in practice be well-behaved :-)


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.