ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google

Mail Archive Home | oscar List | July 2005 Index

<--  Date Index  --> <--  Thread Index  -->

Re: [oscar] UPnP Base Driver 2.0 Ready

Great to hear news about that!
Here are the improvements I think of (very fast because I'm out of the
office for 3 weeks :-)

- Better UPnP error handle: I am looking for a way to have the UPnP
error code. An easy (yet dirty) solution could be to put it in the
exc.getMessage() method. A better solution would be to go further the
OSGI implementation by throwing an UPnPException on UPnP error, that
has a "public int getUPnPErrorCode()" method. This solution is not
against OSGi spec as the UPnPException extends Exception.

- Lesser strict UPnP Stack: I am working with UPnP devices that do not
perfectly implement UPnP. Actually, the first part of the XML file
(description : manufacturer, model, presentationUrl, etc) is correct
but the service part is really bad. These devices does not provide
services, and the service part is like the following :
which makes the BaseDriver to get the resource "/(null)" which throws
a FileNotFoundException and finally to reject the UPnPDevice. It is
too bad, because the UPnPDevice could be created with just the
description and with the getService() method that would return null. I
think you could detect when such error occurs and register the
UPnPService with all the information available (a best effort matter
of acting).

- Device_Category property: the property DEVICE_CATEGORY in UPnPDevice
is written with upper case (see

- PresentationURL : in some bad UPnP devices, this field is relative
(for example: "/index.html"). At the end of the parsing it would be
interesting to check that the PresentationURL is correctly set : for
example you can create a java.net.URL object with the field in
parameter ; if it throws a MalformedURLException, then you can try to
insert the hostname of the device before the PresentationURL and try
again the creation of an URL object.

- Faster discovery : maybe you should take a look at Jakarta
Commons-HttpClient that implements a threaded HttpClient that would
boost the discovery (during my tests, some network protections lead
the Http Get to timeouts. So if base driver wait for each device to
timeout, it takes a long time to get all device available to be

That's it! Well, these are issues I got when I quickly tested your
base driver. I think there is not much work to correct it, except for
the last point. Thanks again for your work.

Best Regards,

Benjamin Chevillon

<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.