hi,
Since HUPnP is distributed under a GPLv3 license and
libsolid (and
Qt/KDE as well) is LGPL, this license incompatibility
wouldn't be a
problem for us? I'm not a license expert, but AFAIK, if a
given
library made under LGPL
hiya,
It will be very tied to the KIO-slave implementation actually, since
KIO does not have a standardized query method, and UPnP also has
sorting, filtering, etc. So we rely on those to be implemented in a
certain way. It's not as simple as using a generic KIO Collection.
You mean: UPnP
hi!
It's unlikely that we will require much more than what Hupnp already
provides, which is a control point, service discovery and action
invocation mechanisms.
I would not say that right away. Although UPnP does seem simple at first
sight there is quite a bit more to it when you want
hiya,
Basic hardware support in Solid would probably be rather trivial but
that's
not what you're asking for here. This sounds like something that
should be
integrated into QCA. I have a card reader and card that I could use
to do
the hardware integration.
That'd be really nice,
On Thu, 2009-01-15 at 09:50 +0100, Bart Cerneels wrote:
The warehouse style tags (or at least their use case) doesn't make
much sense for the average desktop user.
Interesting wording. For the average user: maybe not. For the power
user: it would. I like to think that users of KDE are not
hiya,
after reading the bluetooth discussion I was wondering if support for
other short range communications protocols (zigbee, rfid, z-wave) is
planned.
I'm not sure how it would actually look like, with something like 1
tags near a desktop (think: big warehouse or on board a ship with a
On Wed, 2008-12-03 at 01:14 +0100, Armijn Hemel wrote:
Hm, it might be best if I first draft a plan, where I explain what
needs
to be done.
yes.
Any objections against ASCII art? :-)
hehe. nope =)
OK, will do so. It might take a little while to finish, since right
now
hiya,
[accidentily Aaron did not read headers properly and this list is not
set to 'reply to list, so no one saw his reply. For this, Aaron is
sentenced to the penalty of eating 'two Dutch cookies with pink glazing
without choking']
.. anyways, what's the overhead of this?
any
On Thu, 2008-11-27 at 17:40 -0700, Aaron J. Seigo wrote:
On Thursday 27 November 2008, Armijn Hemel wrote:
Any pros/cons that you can think of?
first, python vs a c++ plugin to kded4 (hm should we allow python addons
to kded? wouldn't be hard, really)
The original plan we had
hiya,
at the Embedded Linux Conference Europe 2008 I talked to Frank Scholz
who works on Coherence, which is a UPnP A/V framework. The ideas
Coherence uses are very similar to what I think we should have: using a
daemon, not a library to handle things like eventing, cleaning up
requests and so
On Sun, 2008-08-24 at 01:34 +0200, Fabrizio Montesi wrote:
/me hears the magic word and jumps into the discussion ;)
Which KDE version do I need to work with JOLIE? Please remember, I
currently use GNOME :-)
armijn
--
-
hi all,
I was thinking: what do you need further to feel confident enough to go
to a sprint and hack on UPnP stuff, apart from time? I can give/make all
necessary documentation.
armijn
--
---
[EMAIL PROTECTED] |
On Sun, 2008-08-24 at 19:41 +0200, Fabrizio Montesi wrote:
On Sunday 24 August 2008 18:13:53 Armijn Hemel wrote:
That would translate in the following JOLIE pseudo-code (example):
// Set the search parameters, like I want a device supporting the full
IGD profile
searchParams
hi,
[snip]
After a fast look the UPnP specs look like a set of mixes of http,
soap and
xml to handle its different tasks (discovery, control, etc.).
HTTP-U (HTTP over UDP) is used for sending announcements to a multicast
address and to devices, SOAP is used for sending control
14 matches
Mail list logo
