Re: Temporary device removal during discovery

[Luiz Augusto von Dentz <luiz.dentz@gmail.com>]

Hi Bastien,

On Thu, Jul 9, 2020 at 1:26 AM Bastien Nocera <hadess@hadess.net> wrote:
>
> On Thu, 2020-07-09 at 01:57 +0300, Andrey Batyiev wrote:
> > Hi Luiz,
> >
> > On Thu, Jul 9, 2020 at 12:14 AM Luiz Augusto von Dentz
> > <luiz.dentz@gmail.com> wrote:
> > > The delta logic might be a nice addition as a separate patch, it is
> > > more for detecting devices disappearing then actually cleanup
> > > during
> > > power off.
> > No-no, it's not about adapter powering off.
> >
> > I meant that (external) devices never disappear from the bluez device
> > list during the discovery,
> > even if the (external) devices are turned off (i.e. they should be
> > purged by bluez).
> >
> > So:
> > - bluez is central
> > - bluez is discovering
> > - peripheral appear for a moment, than disappear (i.e. peripheral
> > would be turned off)
> > - bluez would not remove device from the list (at least until
> > discovery is stopped)
> >
> > Use case:
> > - bluez is monitoring environment (discovering literally forever)
> > - peripherals are brought in and out of bluez visibility range
> > - bluez list of visible devices grows infinitely and causes problems
> > (hundreds of devices)
>
> I'd also expect devices that are recently discovered to disappear if
> they haven't replied to a discovery in 30 seconds. It would stop
> GNOME's Bluetooth Settings's Bluetooth list forever expanding.
>
> Or we need to give the ability for front-ends to do that by exporting
> the "last seen" dates.

I am fine with that as well, 30 seconds doesn't sound too bad even for
cleanup temporary devices as the current 3 minutes seems awful long
sometimes, we could perhaps have a filter for configuring that though
so if the application wants to have its own timeout, the only problem
is if there are multiple application doing that on parallel we would
need a strategy on how to handle that.

-- 
Luiz Augusto von Dentz