<div>Hi,</div> <div> </div> <div>I have a doubt about a situation as:</div> <div> </div> <div>If A party first initiate a text chat with B party, as per my understanding  Mission Control will create a text channel to establish the connection. After some time A or B party upgrade to Voip, along with text chat, then Mission Control again create a media channel to establish the media connection. Are both the text channel and media channel will be in the same session, or both will be in different session? </div> <div> </div> <div>-Regards</div> <div>--Naveen  </div> <div>On 5/3/06, Rob Taylor <<a href="mailto:robtaylor@floopily.org">robtaylor@floopily.org</a>> wrote: <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">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] <a href="http://telepathy.freedesktop.org/wiki/BasicScenario">http://telepathy.freedesktop.org/wiki/BasicScenario</a> 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 _______________________________________________ Telepathy mailing list <a href="mailto:Telepathy@lists.freedesktop.org">Telepathy@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/telepathy"> http://lists.freedesktop.org/mailman/listinfo/telepathy</a> </blockquote></div>