When do I disconnect? Or, research on the "disconnect on close" issue

[Dario Freddi]

Hi guys,

long mail ahead, so don't complain, you have been warned.

This problem has proven to be anything but simple, and to have no 
straightforward solution. So I am going to explain what we are facing first, 
and how we can solve it later.

1. Defining the problem:

We don't know when to disconnect our accounts. There has been an argument over 
disconnecting them after the contact list has been closed, but this would mean 
that any other application wishing to use Telepathy would need to reconnect 
all the accounts.

So, leaving this mechanism inside the presence applet was proposed. Of course, 
this would lead to forcing the user to use OUR presence applet, and that all 
of our infrastructure would hard-depend on it; this is simply not acceptable.

The dataengine seemed a perfect place to aim for an hybrid solution, but 
unfortunately there is no way to detect if any applets are connected to it, 
making it impossible to define when you do not want to be online or offline.

2. Why should I care about presence?

Now try and imagine you are an average developer of a KDE component wishing to 
use Telepathy. Do you care about presence? Yes, but in a read-only fashion. 
Let's try and have a look at a possible workflow the application should have, 
keeping in mind that developers and users should be presented with as most 
simplicity as possible.

Find a schema here (ok, not that great, I used what I found available): 
http://imgur.com/DrIIF

Now, as you see, the contact list is the top of the iceberg: anyone might want 
to know about presence. This brings us to 2 categories of applications:

 - Presence handlers
 - Presence users

Do not need to explain that I suppose. The presence applet would be a presence 
handler. But, we saw that an application should be able to change the presence 
on demand. So, what to do in this case?

3. Centralizing presence handling

In a bright future where we will have a KTelepathy library, one would do 
KTelepathy::init(), which would take care of doing everything which is in the 
box. So an external library would contain all the logic for getting an 
application up and running, which makes complete sense to me.

This is an idea for presence users, but what about handlers? And what about 
handling the disconnection when an user closes?

We need to have a setting somewhere in System Settings which would define 
"Connect always" "Connect on Demand". Now, the second case is indeed easy to 
handle. What about the rest?

We could use a similar approach to what I did in PowerDevil, aka using a lock 
system. We would provide a DBus interface, which would expose a lock() and 
unlock() method. Lock() will return an int "id", which should be passed to 
unlock() when closing the app. When no more locks are present and if the 
global presence setting is "On Demand", the accounts would be disconnected.

Of course, in this case it makes no difference if an application is a presence 
handler or user: both would require acquiring a lock.

Again, this would be handled under the hood by a KTelepathy library

4. Ok, where do I put the DBus interface?

Ah, that's the problem (I mean, the real one). The DBus interface can be 
service-activatable, and we would need a separate daemon for that.

So, schematizing my solution:

1. Create a small daemon which would handle TP-enabled KDE applications locks.
2. Inside it, provide a logic for disconnecting accounts if the user required 
an on-demand connection.
3. Also, provide inside the daemon the logic for requesting to switch from 
offline to online
4. Hook KTelepathy to it.

This looks to me the most logical solution, and of course the daemon can be 
merged with nepomuk-service or the logger, but that's a very small detail. Any 
feedback is more than welcome.

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-telepathy/attachments/20110412/eee9ee91/attachment.sig