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

[Dario Freddi]

2011/4/12 George Goldberg <grundleborg at googlemail.com>

> 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)?
>

To be completely honest, I had the very same feeling. Maybe we should
discuss that with the rest of Telepathers?


>
> --
> George
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-telepathy/attachments/20110412/6e6d975f/attachment-0001.htm