[Kde-hardware-devel] UPnP support in KDE

[Kevin Ottens]

Le Saturday 23 August 2008, Armijn Hemel a écrit :
> That is something I have been thinking about too. I have not found a
> solution I would be happy with. Some explanation:
>
> UPnP has profiles. Part of most profiles are actions. These actions can
> be divided in three groups: required, optional, or non-standard. The XML
> file that can be found in the LOCATION header of the SSDP messages
> points to another file that describes which actions a device implements.
> Of course, not all devices implement all required actions and sometimes
> the XML files do not correspond with what a device really implements (we
> should just call that 'tough luck').
>
> There are two interesting things here:
>
> 1. Do we want to match the SCPD files (with the descriptions of what a
> file can do) and export a subset of the API accordingly to programs, or
> just export the full API and if a program invokes an action that is not
> implemented just return an error? (I think so)

Yup, I agree with you here. If the action is not implemented just return an 
error.

> 2. What do we do with non-standard vendor-specific extensions. An
> example: I have a NETGEAR EVA700 here, which has some non-standard
> extensions to interact with Rhapsody, RealNetworks' online music system.
> Do we add functionality to whatever UPnP lib we make, do we let
> applications decide (that might need to work on a more low level layer
> then), or do we just ignore it?

Well, we can add more interfaces for the vendor extensions we want to support. 
For the other ones will ignore them. But since it's vendor specific I've no 
problem with such an "ignore by default" approach, and plug the hole only if 
we have a need for it.

> I have absolutely no clue how (and if) we want to add support for that.
> I have not seen a lot of devices that implement vendor specific
> extensions. For now I think we can just ignore it, but it might be
> something we need to keep in mind. I guess I will start making a list of
> devices I encounter and document what extensions they have :-)

The way the libsolid API is done it won't be hard to add such extensions after 
the facts in a binary compatible way. And since it'll show as a different 
class in the API too, it'll clearly show it's an extension IMO.

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20080825/7bc4b607/attachment.sig