New location of Cagibi

[Tuomo Penttinen]

Hello all,

On Fri, April 30, 2010 2:57 pm, Nikhil Marathe wrote:
> (_ 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:
>
> 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 :-/

It is certainly possible to modify HControlPoint to allow the user to pass
in necessary device & service descriptions, icons and information found in
SSDP messages. That would save the control point from doing the discovery
and the retrieval of descriptions and icons. From that point on, however,
I think HControlPoint would have to take over and treat the device as it
was discovered. I don't think HControlPoint can rely on user providing
information of SSDP events.

If the concern is in the multicast SSDP alone, there's the possibility of
using unicast discovery too. However, at the moment HControlPoint does not
support this, but I'll definitely add the support for it as soon as I get
my other ongoing tasks done.

Another much more dramatic alternative is to modify HUPnP to use Cagibi or
other similar daemons for SSDP (and even HTTP) messaging, instead of its
own classes.

As mentioned, I will add the support for unicast discovery soon, but the
other approaces require much more thought. Then again, if HTTP messaging
isn't a target of optimization the unicast discovery might just be what
you are looking for.

Regards,

Tuomo