<div class="gmail_quote">2011/4/12 George Goldberg <span dir="ltr"><<a href="mailto:grundleborg@googlemail.com">grundleborg@googlemail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2011/4/12 Dario Freddi <<a href="mailto:drf54321@gmail.com">drf54321@gmail.com</a>>:<br>
<div><div></div><div class="h5">> Hi guys,<br>
><br>
> long mail ahead, so don't complain, you have been warned.<br>
><br>
> This problem has proven to be anything but simple, and to have no<br>
> straightforward solution. So I am going to explain what we are facing first,<br>
> and how we can solve it later.<br>
><br>
> 1. Defining the problem:<br>
><br>
> We don't know when to disconnect our accounts. There has been an argument over<br>
> disconnecting them after the contact list has been closed, but this would mean<br>
> that any other application wishing to use Telepathy would need to reconnect<br>
> all the accounts.<br>
><br>
> So, leaving this mechanism inside the presence applet was proposed. Of course,<br>
> this would lead to forcing the user to use OUR presence applet, and that all<br>
> of our infrastructure would hard-depend on it; this is simply not acceptable.<br>
><br>
> The dataengine seemed a perfect place to aim for an hybrid solution, but<br>
> unfortunately there is no way to detect if any applets are connected to it,<br>
> making it impossible to define when you do not want to be online or offline.<br>
><br>
> 2. Why should I care about presence?<br>
><br>
> Now try and imagine you are an average developer of a KDE component wishing to<br>
> use Telepathy. Do you care about presence? Yes, but in a read-only fashion.<br>
> Let's try and have a look at a possible workflow the application should have,<br>
> keeping in mind that developers and users should be presented with as most<br>
> simplicity as possible.<br>
><br>
> Find a schema here (ok, not that great, I used what I found available):<br>
> <a href="http://imgur.com/DrIIF" target="_blank">http://imgur.com/DrIIF</a><br>
><br>
> Now, as you see, the contact list is the top of the iceberg: anyone might want<br>
> to know about presence. This brings us to 2 categories of applications:<br>
><br>
> - Presence handlers<br>
> - Presence users<br>
><br>
> Do not need to explain that I suppose. The presence applet would be a presence<br>
> handler. But, we saw that an application should be able to change the presence<br>
> on demand. So, what to do in this case?<br>
><br>
> 3. Centralizing presence handling<br>
><br>
> In a bright future where we will have a KTelepathy library, one would do<br>
> KTelepathy::init(), which would take care of doing everything which is in the<br>
> box. So an external library would contain all the logic for getting an<br>
> application up and running, which makes complete sense to me.<br>
><br>
> This is an idea for presence users, but what about handlers? And what about<br>
> handling the disconnection when an user closes?<br>
><br>
> We need to have a setting somewhere in System Settings which would define<br>
> "Connect always" "Connect on Demand". Now, the second case is indeed easy to<br>
> handle. What about the rest?<br>
><br>
> We could use a similar approach to what I did in PowerDevil, aka using a lock<br>
> system. We would provide a DBus interface, which would expose a lock() and<br>
> unlock() method. Lock() will return an int "id", which should be passed to<br>
> unlock() when closing the app. When no more locks are present and if the<br>
> global presence setting is "On Demand", the accounts would be disconnected.<br>
><br>
> Of course, in this case it makes no difference if an application is a presence<br>
> handler or user: both would require acquiring a lock.<br>
><br>
> Again, this would be handled under the hood by a KTelepathy library<br>
><br>
> 4. Ok, where do I put the DBus interface?<br>
><br>
> Ah, that's the problem (I mean, the real one). The DBus interface can be<br>
> service-activatable, and we would need a separate daemon for that.<br>
<br>
</div></div>Thanks for the excellent and thorough writeup.<br>
<div class="im"><br>
><br>
> So, schematizing my solution:<br>
><br>
> 1. Create a small daemon which would handle TP-enabled KDE applications locks.<br>
<br>
</div>I can't help wondering - is this really KDE specific? If not, then<br>
perhaps a solution needs to be discussed with upstream. Perhaps this<br>
belongs in the Account Manager (Mission Control)?<br></blockquote><div><br></div><div>To be completely honest, I had the very same feeling. Maybe we should discuss that with the rest of Telepathers?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
--<br>
<font color="#888888">George<br>
</font></blockquote></div><br>