[Kde-hardware-devel] Fwd: HUpnp, Solid and changes in the slave

[Paulo Rômulo]

Hello,

Since looks like the item 3 (below) it's a general Solid issue (regarding
with the backends management) I think the rest of the list should be aware
of it...

*3) Due to the use of a QThreadStorage on the backends manager, a new
HControlPoint is created for every UPnPDeviceManager created. This may
cause issues where in the thread affinity decides which HCP is queried
and which HCP monitors and so on, leading to wrong results. Every user
of Solid should have only one HControlPoint, irrespective of the
number of threads.*

Thanks, Nikhil, I'm working on the UPnP backend issues you pointed out.

Regards,
--
Paulo Rômulo Alves Barros
MSc. Candidate in Computer Science
Embedded Systems and Pervasive Computing Lab
http://embedded.ufcg.edu.br/indexen.html





---------- Forwarded message ----------
From: Nikhil Marathe <nsm.nikhil at gmail.com>
Date: Sun, Jul 25, 2010 at 8:19 AM
Subject: HUpnp, Solid and changes in the slave
To: Paulo Rômulo <p.romuloo at gmail.com>
Cc: Kevin Ottens <ervin at kde.org>, Bart Cerneels <bart.cerneels at kde.org>


Hi,

Over the past few days I've been grappling with various issues related
to HUpnp support in Solid and using it in a kioslave and things like
that. I have a few comments about the Solid code, and changes I've
made in the slave and how Solid UPnP will fit into my project.

Solid UPnP backend changes
=================

There are some issues in the current code which should be fixed
immediately since it is not the right way to use the HUpnp library and
will lead to crashes or errors.

1) UPnPDeviceManager::allDevices(). The call to scan is treated as if
it is blocking. HControlPoint::scan() is non-blocking. Which means any
devices detected by the scan will not be reported in rootDevices()
since they haven't been detected when that code is reached. The scan
should be abandoned, because allDevices() should return what the HCP
knows about. HCP automatically scans and stores internally.

2) UPnPDevice destructor SHOULD NOT delete the internal HDeviceProxy,
that is managed by the HCP.

3) Due to the use of a QThreadStorage on the backends manager, a new
HControlPoint is created for every UPnPDeviceManager created. This may
cause issues where in the thread affinity decides which HCP is queried
and which HCP monitors and so on, leading to wrong results. Every user
of Solid should have only one HControlPoint, irrespective of the
number of threads.

4) UPnPDeviceManager::rootDeviceOffline() Again a device is being
explicitly removed when it is not required. This won't cause crashes
or anything but seems redundant.

The slave
======
I am dropping Cagibi and Solid support from the slave. The slave has
to perform actions on the remote devices and so requires a
HControlPoint anyway. This HCP is perfectly capable of detection and
so it is a double effort to use either Cagibi or Solid to first
confirm the device is up and then make the HCP scan for it and
initialize its internal device model. So in the most recent commit of
kio_upnp_ms, I have no external dependencies on these 2.

The Amarok collection
=============
Staying true to Solid's purpose of device detection and notification,
the Amarok UpnpCollectionFactory WILL use Solid. This way it can see
devices coming or going and create appropriate Collection instances.

I saw in the post Akademy notes that Solid is aiming for UPnP
integration in 4.7. In my opinion that is too late. I would like to
aim for 4.6, because Cagibi is not extremely high quality and fails to
detect a lot of devices. It would be foolish to rely on it when we
have a better alternative. I understand that Solid being a core
library has to make decisions keeping things like Binary Compatibility
in mind, but I am willing to spend time on the backend to make it
stable and tested if that is the case.

With Amarok aiming for UPnP support as soon as possible, it would be
great if Solid can provide the required support.

@Bart: I've fixed the slave, no crashes anymore, HUpnp does have a
bug, in the sense that it calls processEvents() once before exiting
and bad code elsewhere may make it crash too. Tuomo is aware and
thinking of a solution.

@Paulo: The above thing about HUpnp crashing while processing events
might affect you, but it happens in a not easily reproducible
situation. I think if you did constant tests with it, you might be
able to help him pinpoint the reason.

Thanks,
Nikhil

--
Support open formats.
Don't send me files in proprietary formats like .doc, .xls, .ppt.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20100726/c12dd994/attachment-0001.htm