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

[George Goldberg]

2011/4/12 Dario Freddi <drf54321 at gmail.com>:
> 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.

Thanks for the excellent and thorough writeup.

>
> So, schematizing my solution:
>
> 1. Create a small daemon which would handle TP-enabled KDE applications locks.

I can't help wondering - is this really KDE specific? If not, then
perhaps a solution needs to be discussed with upstream. Perhaps this
belongs in the Account Manager (Mission Control)?

--
George