[Telepathy] MC5 and my GSoC project for Banshee
neil.loknath at gmail.com
Sun Jun 21 21:14:18 PDT 2009
On Sun, Jun 21, 2009 at 7:55 AM, Sjoerd Simons <
sjoerd.simons at collabora.co.uk> wrote:
> On Thu, Jun 18, 2009 at 04:14:10PM -0600, Neil Loknath wrote:
> > Hey everyone!
> > My name is Neil (nloko on IRC), and I'm working on the Banshee with
> > Telepathy Integration project for SoC . As I understand it, MC5 is
> > soon. If you've seen my blog posts , you know that I've made some good
> > progress on it. Therefore, I will need to make some changes to my project
> > when Empathy is ported to MC5. I thought it would be a good idea to get
> > feedback on what I think I will need to change. I've already had some
> > discussion with wjt on IRC, but more information/confirmation on what I
> > need to do will be very helpful. See below:
> > 1) Currently, I am using MissionControl.AccountStatusChanged signal to
> > detect when connections become active/disconnected.
> > MC5: Use Account.AccountPropertiesChanged 
> > 2) Using MissionControl.SetPresence to set presence message (I know
> > would be more appropriate, but since it's not there, I am making due with
> > this)
> > MC5: Use Account.RequestedPresence property ??
> ... Please don't do this, it's very annoying.. But if you really want to
> yes, Account.RequestedPresence is the most appropriate.
> > 3) I'm using the ContactListChannel, Group, and SimplePresence interfaces
> > find contact, track presence, etc.
> > MC5: Assuming that nothing here will have to change
> Correct, the only thing that differs here is how you would get the initial
> Connection object, after that you can do all the same things.
> > 4) Using ContactCapabilities.SetSelfCapabilities to advertise my DBusTube
> > service. And, using ContactCapabilities.GetCapabilities to find out if
> > contacts support my service.
> > MC5:
> > * Register dbus name org.freedesktop.Telepathy.Client.clientname,
> > (where clientname = Banshee ? ), that points to an object implementing
> > org.freedesktop.Telepathy.Client.Handler . Set the
> > property to the channels that are to be handled by Banshee. Banshee
> > be a non-activatible client, so no .client file.
> Yeah. You register org.freedesktop.Telepathy.Client.Banshee which
> org.freedesktop.Telepathy.Client and
> interfaces. The Interfaces property on Telepathy.Client should contain
> Client.Handler. And as you say the HandleChannelFilter contains the
> handled by Banshee
> > * Implement the HandleChannels method to handle my channels (ie.
> > accept/close tube). This makes handling the NewChannels signal of the
> > Requests interface obsolete, correct? In other words, I won't need it.
> Yes. NewChannels will be handled by MC5 and it'll call your HandleChannels
> method if you are the choosen handler for the channel.
> > * I don't need to implement Client.Approver  as well, do I? It
> > seems redundant to me.
> You don't have to (and probably shouldn't) implement an approver indeed
> > * Can ContactCapabilities.GetCapabilities and
> > ContactCapabilitiesChanged signal still be used to discover what
> > other contacts provide? I use this to filter out contacts that don't
> > to Banshee, since they can't participate in sharing.
> Yeah, that'll stay the same
> > 5) I'm using the Requests Interface  to create channels and detect new
> > ones. On NewChannels signal, I compare SelfHandle to InitiatorHandle to
> > determine where the channel is coming from and take the appropriate
> > MC5: Should I use org.freedesktop.Telepathy.ChannelDispatcher 
> > instead? And, pass it my Banshee Client.Handler dbus name?
> Yes, use CreateChannel on the ChannelDispatcher and pass yourself as the
> preferred handler for that channel.
> > And, as I have said above, Client.Handler.HandleChannels replaces the
> need to
> > handle the NewChannels signal, right? Or, should I still use the Requests
> > interface?
> Nope, as mentioned above, the dispatcher does the job of requesting
> and demultiplexing incoming channels so you don't have to use the Requests
> interface directly.
> > Long post! But, this information will be very helpful to me, and maybe
> > others too. If there is anything else you think I should know, please let
> > know. I hope I have covered everything.
> > Thanks in advance for your help with my project
> No problem, sorry for taking quite some time to get a response to you :)
Response time was just fine. No complaints. :) I appreciate you taking the
time to respond.
Now, I know that I will definitely have to change how I query for active
connections, monitor them, presence setting, etc. with MC5. But, it seems to
me that using the org.freedesktop.Telepathy.Client, Client.Handler,
ChannelDispatcher, etc. interfaces are just a higher level layer above what
I am doing now. ie. interacting directly with the CM via the Requests and
So, what disadvantages are there to sticking with the Requests and
ContactCapabilities interfaces instead of using the new MC5 things?
I know that, since SetSelfCapabilities does a replace operation, I would
have to aggregate the existing advertised capabilities by doing a
GetContactCapabilities, either adding or removing my tube service (depending
on what I want to do at the time), then calling SetSelfCapabilities with the
appropriately aggregated/manipulated dictionary passed. However, I think
this introduces a race condition where the capabilities could change in
between the time that do my Get, and manipulate, Set. That, unfortunately,
might become difficult to manage and introduce bugs when a user is running
more than one Telepathy service.
But, by sticking with interacting directly with the CM, are there any other
disadvantages that I'm overlooking?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the telepathy