New location of Cagibi

[Nikhil Marathe]

(_ sent to Tuomo and Amarok-devel since it could be useful/important
to other concerned with this project _)
On Tue, Apr 27, 2010 at 5:07 PM, Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
> Hi Nikhil,
>
> congratulations for being accepted as GSoC student for KDE!
> Looking forward to browsing the MediaServer stuff soon :)

Thanks. I'm looking forward to some great hacking.

> In case you continue to play around with Cagibi (which I of course think you
> should ;) ), you should know I just moved it to trunk/kdesupport/cagibi, as I
> am going to use it for the network:/ kio-slave at least for the 4.5 release.

I am experimenting with the following situation.

1) The slave uses Cagibi for discovery and getting device details
2) Only when a actual browse of the device is requested, is HUPnP
started. Its Control Point is initialized to not scan for devices.
Instead the UDN is passed to it, and the control point only looks for
that device and continues browsing.

I've got Cagibi listing the devices right now, but I need to convert
the struct and I'm feeling quite lazy right now, so see the end of
this email :-)

Of course the above will be rendered useless if the network:/ slave
will boot my slave directly with the UDN, so I'm not much concerned
with that. If Cagibi gets moved lower down the stack and upnp
detection gets wrapped into Solid as part of the other gsoc project,
well and good. But I would still prefer to do actual browse calls in
C++ and not D-BUS, since the UPnP type system is already one layer of
conversion that has to be done.

Tuomo: Would it be possible for HUPnP to load a service/device
definition from a XML description received as a string, and integrate
it into the HControlPoint. That is, I pass the control point the XML
and it creates a device without any network activity, or validation,
on the assumption that the source of the XML knows what is happening.
Or a device is created based on passing the description location URL.
The important thing is that no SSDP discovery is performed. Of course
this might be a bit stupid, I only asked because doing another network
query when we already know the device status from Cagibi is a waste.
Of course then it becomes the caller's responsibility to also notify
of device removal. Some food for thought :-/

>
> Please report any troubles you may have while building, as I now had to turn
> also the buildsystem to be independent from the KDE platform and could have
> failed somewhere.

Well it would be really useful if the dbuscodec and device header
files could be put in the standard include directories during
installation. That way a user of Cagibi over D-BUS could convert the
reply from 'deviceDetails' back to a device representation.

Regards,
Nikhil