2011/4/12 Dario Freddi <[email protected]>: > 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 _______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
