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

[Nikhil Marathe]

On Mon, Mar 29, 2010 at 7:05 PM, Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
> Not readable for me:
> "Error. You need to be in the admin group to read documents in the user prefix."

socghop isn't working properly right now, so I can't go and change
permissions. Meanwhile please see the unformatted version at
 nikhilm.webfactional.com/proposal_socghopcopy.txt

> > 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.

You're probably right in needing a specific lib. If you want to keep
it generic you will be able to do, Is Storage and 'supports query' but
how does amarok determine whether the device supports advanced meta
data based queries and so on?

> Samedi, le 27 mars 2010, à 18:48, Nikhil Marathe a écrit:
>> I'll be sticking to Coherence, as soon as I can get action invocation
>> going on some device via D-BUS. The current kioslave or solid backend
>> don't seem to do this either.
>
> Sadly I haven't been much successful so far at this during some private
> experiments, neither. All D-Bus calls just hang or time out.
> But I just reported this by email to the main developer, did not create a
> ticket for that.

The trick is to use lowercase action names ie. browse rather than
Browse, that was what was tripping me up. But that apart we are
investigating Hupnp too, and thinking of a little abstraction layer so
we can plugin both.

> > 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

By spawning I meant having a slave launch another slave to do actions
for it. I'll look into UDS_TARGET_URL with a test example

Regards,
Nikhil