[Telepathy] Welcome to our project page..

[NAVEEN VERMA]

Hi,

I have a doubt about a situation as:

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?

-Regards
--Naveen


On 5/3/06, Rob Taylor <robtaylor at floopily.org> wrote:
>
> 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
>
> _______________________________________________
> Telepathy mailing list
> Telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/telepathy/attachments/20060503/615c4b95/attachment-0001.htm