[Telepathy] Requestotron use-cases, part 7 (starting to propose implementations)

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 06 Jun 2008 at 15:18:00 +0100, Alban Crequy wrote:
>  - What are the use cases for NewDispatch and DispatchFinished signals?

Um... a general feeling that whenever we have a property, there should
be change notification :-)

I'm not sure whether the property (and its associated signals) makes
sense, though. Perhaps it does for state-recovery purposes.

> Does the order between HandleDispatch method calls and NewDispatch
> signal matter? And between HandleChannels method call and
> DispatchFinished signal?

Entirely unspecified at this point.

>  - What will happen to the current RegisterFilter MC API? Will it be
> removed and replaced by something?

It's being replaced by approvers and observers. Anything that has to
delay channel processing will have to be a C filter inside MC - I don't
think allowing arbitrary filters like in the old API is sufficiently useful
to be worth the cost in terms of complexity and potential for things to
go wrong.

>  - The dispatcher has to know the list of Client.Approver. How? Will it
> use D-Bus activation? Should it be documented in the spec (where)?
> 
>  - How does the dispatcher know the list of Client.Observer?
> 
>  - How does the dispatcher know the list of Client.ChannelHandler?

All of these will be documented in the spec by the time it's finished.
The idea is that all running or activatable processes with a well-known
name of the form org.freedesktop.Telepathy.Client.something will be
probed by the channel dispatcher (by getting a property on a well-known
object path, probably) to discover their capabilities.

As an optimization, there will be some sort of .client file (similar to
.manager files) so that for most clients, the channel dispatcher can
just read a file instead of service-activating the client straight away.

>  - Client.Approver approves a channel bundle and Client.ChannelHandler
> handles a channel bundle. Why Client.Observer receives the
> ObserveChannel method call with only one channel?

I'm not sure that observers have any useful interaction with dispatch
operations (they're meant to be entirely read-only, after all...),
although we could change this just to make it consistent.

>  - In case of an Client.ChannelHandler that wants to log text
> conversations, how can we guaranty that the observer get all text
> messages? The channel handler can be already started and acknowledges
> text messages before the observer is activated by D-Bus (race
> condition).

A good point. We should avoid this somehow.

On the other hand, I don't like the idea of having channel handling wait
for a (possibly crashed or hanging) client process to say "continue".

>  - The dispatcher calls HandleDispatch with the list of handlers as a
> parameter. If the approver chooses to call HandleWith, can it choose
> an handler that is not in the list?

No, I don't think it should.

>  - HandleDispatch: "Processes that aren't approvers shouldn't be making
> connections anyway" --> what does mean making connections? (A D-Bus
> connection?)

A Telepathy connection. The idea was: Mission Control shouldn't be told
to put accounts online unless some sort of Telepathy UI is running. That
Telepathy UI should be an approver.

>  - dis5b: How does the channel dispatcher know the Juliet's VoIP UI
> caps? Is it HandledChannelClasses on
> org.freedesktop.Telepathy.Client.DRAFT? What should do the channel
> dispatcher if the client does not implement this property?

Those properties (or whatever we replace them with after some more thought)
will be mandatory. If clients don't implement them, the fallback
behaviour will be to treat a missing property as equivalent to the empty
list, meaning that the client will never be considered as a possible handler.

    Simon
-----BEGIN PGP SIGNATURE-----

iD8DBQFISUvhWSc8zVUw7HYRAl/rAKDKGiOWxyCgc42G8GIT8AmztvkjcQCgum/7
nqdr0MFTFbzrOe3gx+ekKzs=
=jaXz
-----END PGP SIGNATURE-----