[Kde-hardware-devel] Solid UPnP GSoC idea

[Kevin Ottens]

On Sunday 11 April 2010 17:02:12 Friedrich W. H. Kossebau wrote:
> Jeudi, le 8 avril 2010, à 23:57, Kevin Ottens a écrit:
> > Not sure what you have in mind here with "module". But the way I see it,
> > the only thing required would be a Solid::NetworkGateway class
> > (inheriting from DeviceInterface) which would provide two methods (one
> > to open a port, one to close it). This way once you get a hold on a
> > device which is IGD you could just:
> > Solid::Device d = ...;
> > d.as<Solid::NetworkGateway>()->openPort(...);
> > ...
> > d.as<Solid::NetworkGateway>()->closePort(...);
> > 
> > Sounds fairly easy to use from any application out there.
> 
> Just that this enlarges the Solid lib for every program using Solid, most
> anything but interested in punching gateway holes.

Yes, it enlarges it by one class (API wise). I don't really see that as a 
problem, it's part of the libsolid design decision since day one. We give 
access to all the hardware, up to us to actually make sure we have things 
which are not only interesting to a single app or policy agent in there.
 
> Shouldn't this be rather part of some SolidControl lib?

Nope, as the plan is to make solidcontrol disappear mid/long-term.

> Or being solved by some dl'opened plugin for each device implementation?

Well, then you tie up frontend and backend together? Doesn't seem like a good 
idea.

That said, part of the libsolid architecture changes I have in mind is to 
allow not loading some of the backends if you're not interested in their 
capabilities. That's still in the "not done" department though.

> > I'd say no. That'd definitely be opening the pandora box. :-)
> > 
> > I think we should limit ourselves to multimedia devices/network storage
> > (just like we used to report media players... but now they're connected
> > via ethernet/wifi and not simply USB) and to those very focused headless
> > devices (network gateway, possibly home automation devices).
> > 
> > "http server" lacks some focus I'd say. We shouldn't simply report
> > anything which has a port open to the outside. ;-)
> 
> Why not?

Because at one point we have to draw a line in the sand or it'll get 
unmanageable...

> After all it's a property/ability of that device/hardware. Where
> else should it be reported? And how would you think the overlap should be
> handled, if it was reported elsewhere?

I think one should have to think about use cases of the library really. In the 
case of UPnP for instance it's fine to add it as we have some well known 
interfaces to it, it's really a consumer electronics oriented protocol. So you 
get a communication channel with a specific device feature and you can drive 
it (just like USB, only it's on an IP stack).

If you start pulling http into the mix it's much more different as it's too 
generic. You've no idea what can be done with the device feature apart  from 
pointing a web browser to it. And since we're at it we could report imap, 
smtp, ssh? Now we're dealing with general purpose network protocols, not 
device access protocols.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20100412/97f81609/attachment.sig