2011/4/12 George Goldberg <[email protected]> > 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)? >
To be completely honest, I had the very same feeling. Maybe we should discuss that with the rest of Telepathers? > > -- > George >
_______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
