[Kde-hardware-devel] [GSoC] Preliminary UPnP support proposal

[Friedrich W. H. Kossebau]

Samedi, le 27 mars 2010, à 19:30, Nikhil Marathe a écrit:
> On Fri, Mar 26, 2010 at 6:56 PM, Friedrich W. H. Kossebau
> 
> <kossebau at kde.org> wrote:
> >> As for the UPnP spec, I think that Solid should export a generic UPnP
> >> device system,
> >
> > What do you mean by this? Solid objects which implement a special
> > UPnPInterface interface?
> >  Wouldn't it be better if we could hide implementation details as much as
> > possible? Like one does not scare if it is a IDE or SATA hard disk, they
> > are all wrapped behind a neutral interface at the next level.
> 
> Well I'm not sure if the exact situation applies. IDE and SATA might
> have different capabilities, but they aren't user/application level
> capabilities.

It was meant as an example for abstraction, independent of the layer :)

> UPnP on the other hand is quite different from other
> protocols,

Is it? It's just a bigger bundle of specs for more things than usually, like 
both discovery, device access and device implementation. These could (and 
should) be treated independently.

Just compare the detection and interaction of UPnP MediaServer with Zeroconf + 
DAAP (besides DAAP being proprietary und not yet reverse-engineered).
Is there really a fundamental difference in the architecture?

> and in this case applications are interested in the unique
> features of a UPnP device, so I think it should be offered by Solid.
> That way Solid could directly give an app the exact UDN of a device
> based on "Does a device support media server 3 capabilities" or
> something.

For sure that is possible. But it also means a direct dependency to that 
specific technology, both in API, terms and thinking. And it also breaks the 
logic: Why do you want to wrap UPnP stuff in Solid to only keep on using UPnP 
stuff on both sides of the Solid layer? A dedidated specific lib would after 
all be much more suited, then.

As I said, IMHO we should at least try to hide as much as possible behind 
generic interfaces, so application code does not need to be rewritten if one 
day another alternative technology arises which could be mapped to the same 
principles.

On the other hand I agree with you that for a quick start there could be a 
dedicated interface which could be used to query all the infos available about 
a UPnP device. But later on it should be tried to emerge all that into (new) 
generic interfaces.
But let's first get some use-cases together to see which kind of data needs to 
be made available at all :)

> >> For the protocol prefix, well I think upnp:/ makes more sense because
> >> we are 'browsing UPnP devices'. Then for certain device types, we can
> >> have upnp-<type> slaves.
> >
> > Why would you want to do a kio-slave to browse just UPnP devices (on the
> > discovery level)? The network:/ kio-slave does that already. Where would
> > you need that?
> > Do you think the user cares for this implementation/technique detail and
> > says, hey, let's browse just my UPnP devices? ;)
> 
> Well we let the network:/ slave handle discovery, but when a user
> selects a device, we invoke the upnp:/ Actually is it possible to
> spawn a slave from another slave? that would simplify stuff a lot. The
> user would keep seeing network:/ but apps could use the exact slave
> they require.

Would do you mean exactly with spawning?

If I guessed it correctly: The way it's currently done is that a (meta-)kio-
slave sets the property UDS_TARGET_URL [1] for those items in a listing which 
are to be handled by another kio-slave for that item-specific protocol.

[1] http://api.kde.org/4.x-api/kdelibs-
apidocs/kio/html/classKIO_1_1UDSEntry.html#a8c3c5c6ee998a9f0e413b8aafcc98597abfdec1a67cc84d3f478ec6dc3281bdb7

Cheers
Friedrich
-- 
KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta