felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nektarios K. Papadopoulos" <npapa...@inaccessnetworks.com>
Subject Re: Domoware UPnP Base Driver
Date Tue, 20 Dec 2005 12:12:11 GMT
Hi André,

I'm not sure about this, so I did some research and here is what I found:

OSGi spec (R3, and R4, explicitly states that "This 
method does *not* substitute missing properties with their default locale versions."

Therefore, a UPnP Base Driver should return null if the device is not providing 
a Description in the specified locale.

If I interpret the UPnP Device Achitecture document correctly (both 1.0 and 
draft 1.0.1) the proper way to retrieve a locale specific description is include 
an "ACCEPT-LANGUAGE" header in the GET request.
The device is then allowed to return a default-locale description in case the 
requested is not supported, but *must* include a "CONTENT-LANGUAGE" header 
stating the language being used.

OTOH, I manually sent such a request to several media servers specifying various 
- Intel AV Media Server (windows)
- Intel Micro Media Server (posix)
- MediaTomb 0.8.1  (linux/libupnp)
- Gmediaserver 0.8.0 (linux/libupnp)

None of them ever returned a "CONTENT-LANGUAGE" header. AFAICT this is violation 
of the spec, but I'm not sure how a control point should treat such behavior.

Anyway, I'd vote for the Domoware UPnP Base Driver being more correct, since the 
device fails to correctly associate a descritpion response with a language and 
OSGi requires the base driver not to substitute properties with their default 


> When I write UPnPDevice.getDescriptions("en") (instead of
> getDevice().getDescriptions(null)) in some programs discovering Intel Media
> devices, it returns a null value whereas it returns the expected description
> with ePerSpace UPnP Base Driver I am testing right now. Which Base Driver is
> carefully implementing the spec ? ;-)
> André

View raw message