Hi Francesco,
We haven't formally compared Youpi vs Cling.
The reason for that is that if Cling had been out a few months earlier,
we would not have wasted time creating a new implementation...
Unfortunately, I think 2 or 3 projects simultaneously worked on UPnP
without being aware of it. But in the end, I'm glad that we achieved
similar features (like the annotation mechanism), it shows there was a
real need for that.
From what I've seen (I had taken a look at it a few months ago), here
are some differences I noted:
* The Cling project is a bit more modular, it relies on message
passing between modules that implement the different features:
registry, discovery, subscription... Though we decoupled many things
compared to Cyberlink, our implementation is more monolithic. It
means less message passing (possibly better performance but I can't
really say as there was no real comparison made until now) but maybe
it is less easy to understand.
* Defining UPnP actions through annotations:
- In Cling, you use basic data types to define action arguments
(boolean, int...)
- In Youpi, you use a wrapper type (e.g. Var<String>, Var<Boolean>)
The Cling way is less verbose, but what happens with the output
arguments? It's ok when there is only one (it is the return type of
the method) but the UPnP specs allow for multiple out args... For
that reason, I used a wrapper that allows to actually change the
value of arguments in the body of the method.
Moreover, this solution allows to enforce range and value
restrictions as defined in the UPnP specs. I'm not sure how Cling
handles those two important points of the spec.
* The licensing is different. Cling uses LGPL whereas Youpi is CeCILL
(i.e. BSD).
* The last point (but not the least, imho) is that Cling is a weighty
library of 3MB (I wonder why...) whereas Youpi is very lightweight
(600KB).
* Finally, concerning the graphical tools, Youpi and Cling seems to be
on the same level. Cling provides specific handling of Gateway
devices (which Youpi don't) and Youpi provides automatic java code
generation (which I don't think Cling proposes).
Now, concerning the base driver re-factory, I don't think there is any
need for an abstraction layer. The OSGi specs for UPnP already is such
an abstraction layer. So ok, if you want to implement a wrapper for a
new UPnP library, you have to rewrite it... But there is not magic, if
you have a new abstraction layer, you will have the same amount of work
wrapping your new library (be it Cling or Youpi) within this layer... So
I wonder what's the point, but again, I'm not sure I've perfectly
understood what you propose.
On the other side, if you want to make evolve the OSGi specs for UPnP
(which are very basic), then I understand that you could do it so that
it is not too hard to wrap Youpi and Cling with it ;-) I would suggest
to add some concepts: the control point and device server appear nowhere
in the actual specs, so we cannot change their config in OSGi, which is
a pity. Apart from that, I don't know how to improve the specs, I guess
there is some work here to analyse the APIs of Youpi and Cling more in
depth.
I've been a bit long, but I hope this was helpful.
Best regards,
***********************************
Gaëtan PRUVOST
LIMSI-CNRS BP 133
91403 Orsay Cedex France
Tel:+33 1 69858110
http://www.limsi.fr/Individu/pruvost/
***********************************
Le 31/03/2012 10:08, Francesco Furfari a écrit :
Hi Gaëtan,
nice to hear from you again,
I have a question.
Did you never compare your implementation with Cling?
Well not just in terms of performance but in terms APIs and architecture.
One possible Base driver re-factory could be the inclusion of an
abstraction layer to be independent from both Yuopi and Cling.
Francesco
On 30/03/2012 9.57, Gaëtan Pruvost wrote:
Hi guys,
Yes indeed. I'm sorry but I've been a bit overwhelmed with the phd
writing and my baby son... I would really like to participate to the
felix apache project but unfortunately, I really don't have time
right now.
The Youpi library is already fully functional. It provides a stable
kernel wrapped in a Cyberlink-like API.
*It also features POJO definition of your UPnP devices using
annotations*.
Another important feature is the set of graphical tools it includes,
especially the Network explorer that *can generate skeletons for your
XML or Annotated Java code*.
Compared to Cyberlink, we achieved better service discorvery (80+
devices in the atraco testbed) and a clean subscription mechanism. I
also tried to limit the consumption of threads by using messages
queues and thread pools. Finally, data passed to actions are typed
checked and value constraints defined in the XML are automatically
applied.
Further details on the project webpage:
http://perso.limsi.fr/pruvost/software-youpi--en
A short documentation is already available. I will take some time off
my sleep to make it more detailed.
*If people inside felix-dev are eager to use Youpi with OSGi, Yiannis
Liverezas wrote a bundle but as far as I know, it needed some
cleanup. I can't write the new bundle myself but I will definitely be
there to provide support (via mail or skype) and I can grant you
access to the SVN.
*
Best Regards
***********************************
Gaëtan PRUVOST
LIMSI-CNRS BP 133
91403 Orsay Cedex France
Tel:+33 1 69858110
http://www.limsi.fr/Individu/pruvost/
***********************************
Le 30/03/2012 07:11, Francesco Furfari a écrit :
Hi,
cybergarage seems again active, different e-mails exechanged recently.
By the way, I know about a new implementation derived from
cybergareage called YOUPI that is available at
http://sourceforge.net/projects/youpi/.
It is developed by Gaetan Pruvost and relesed with CeCILL-B license,
and should fix several issues there are with cybergarage.
In the framework of the ATRACO project, Yiannis Liveresaz starting
from the Felix UPnP Basedriver wrapped the Youpi library to provide
a more stable version of the UPnP Base driver.
We discussed a bit different months ago, but I have not heard for
some time.
Francesco
On 30/03/2012 1.58, Loic Petit wrote:
Hi,
In OSGi, there is the concept of basedriver (which is
standardized). Basically, all remote and local devices are
registered on the service registry as
org.osgi.service.upnp.UPnPDevice services.
Then, it is just a matter of filtering on service properties to get
the device you want and call actions on its service. A simple
documentation is available here:
http://dz.prosyst.com/pdoc/mbserver_5.2/um/upnp/developer/osgi_upnp/osgi_upnp.html
Cling does have a basedriver wrapping (cling-osgi) which is working
fine from the trunk (not released yet I think). Felix also have an
implementation based on cybergarage which was less stable last time
I tested it, though I dunno if cyberlink is still maintaining this
stack.
LP
Le 30 mars 2012 à 01:48, Ken Gilmer a écrit :
Hi Maria,
I have used the Cling UPnP library, however not within an OSGi
context (Android). The API is very clean and I did not have much
trouble in using it. I'm not aware of any issues with OSGi or Felix
in particular and the library is actively maintained.
http://4thline.org/projects/cling/
Hope that helps,
-ken
On Thu, Mar 29, 2012 at 8:11 AM, Maria
Luiza<[email protected]> wrote:
Hi,
Has anyone used Felix to interact with UPnP devices? If yes, how
do I?
Regards,
Maria
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
