[Telepathy] Welcome to our project page..

[Rob Taylor]

Kai Teuber wrote:
> Hi,
> 
> after comparing the basic use case from the telepathy website [1] with our 
> diagram 'outgoingconnection' [2], I don't see why everything should be wrong. 
> There are some small differences, but only answering questions won't help  
> bringing up an architecture.
> The main difference is that you are using a contact manager, which wasn't 
> declared within the specification. This functionality is include in our 
> mission control.
> Btw.: I'm not sure whether your are really separate presence information, 
> contact information and information needed for connections itself (like 
> passwords, etc.) which may be stored in different desktop components.
> 
> Here's what the basic use case provides and what we have written down:
> 
> 1.Albert logs in
> - System startup was not covered by us.
> - Since there wasn't a contact manager within your specification we thought 
> mission control manages the contacts.

well, this is an interesting question. Of course the connection manager
fetches your contact lists off the server, just as in any normal IM
client. It gets interesting if you also want to synchronise your remote
contact lists with a local address book. If so, this requires some very
serious state diagramming... ;)


> 2.Albert views contact list
> - The client UI requests contact list – how did that start up? To provide a 
> universal interface we called it desktop UI.

If its the remote contact list, it can just read these off the
connection manager - they appear as Channel.Type.ContactList channels.
See the spec for more details.
If you want to do integration with an address book, then you probably
don't want the client UI displaying its own contact list.

> - As our Mission Control is managing the presence information,  it has to stay 
> updated. You solution to receive signals by the connection managers is the 
> better solution than our “polling”!

MC should just manage setting *the users* presence. Anywhere you want
presence to be displayed in the desktop, it should directly listen to
signals from the connection managers.

> - The contact manager has to match possible communication types - that's what 
> we do with mission control.

Not sure what you mean here.

> - Client displays contact list – exactly the same.

> 3.Albert initiates chat with Bertha
> - Albert selects Bertha and chat – same here just called 
> 'wait4UsersSelection()'

> - Client UI asks Contact Manager for all possible methods of forming a text 
> channel to Bertha – just called 'establishConnection()'

This is interesting - you're basically selecting which conn manager to
use here. I'm not sure if this is actually an M/C feature or if it would
be better to have library functions for choosing connections, possibly
with some sort of offline-store for preferences.


> - Somehow it is necessary to see if the needed resources are available – does 
> the contacts manager check these too?

Which resources are we talking about here? that we're connected -
mission control should know this. That we have a video camera? that's a
complete other kettle of fish.

> - A difference: we start up a matching client now – yours was already there. 
> Is the client responsible for starting a matching connection manager?

Nope, I'd say Mission Control should always be the one launching
connection managers, and m/c should just have a dbus interface for
setting the current presence (available, away, offline, etc) and should
bring up and down your configured connection managers as needed.

> - What happens if additional clients are needed? Who is starting them?
Mission control, for sure. What scenarios are we talking about here?

> - Also we provide the connection informations to Client & Connection Manager.

Client doesn't need connection information, just CM.

> 4.Bertha accepts
> - we only looked at one communication partner's side at the moment

Again, all these situations are already implemented, so I suggest you
look at one of the existing ui's and document the current behaviour.
*Then* we can think about the more complex situations.

> What's the job of mission control? Only startup connection managers and read 
> configuration files? This is less than stated in the archtecture overview, 
> provided on your page!
> 
> [1] http://telepathy.freedesktop.org/wiki/BasicScenario

Umm, in this scenario, the only steps involving mission control are:

# Mission Control starts up, reads configuration and credentials.
# Mission Control starts Connection Manager(s) as per configuration,
passing in login credentials.
# Mission Control shuts down all Connection Managers. Connection
Managers signal their shutdown on the bus.

Are you getting Contact Manager (aka your address book) confused with
Mission Control here? Also note that that scenario is pretty old so
lacking a lot of detail, but the basics seem about right.


Thanks,
Rob Taylor