Hi Jackson,I think that we should not miss the opportunity to propose requirements that facilitate the effective use of UPnP Spec, for example to build DLNA compliant products.
The new specification could include new conventions that can be easly adopted by UPnP implementations. The Patrick's solution follows this line, but in my opinion it is a vertical solution to solve only the DLNA's requirements. Moreover it helps only to export DLNA devices, but nothing is stated about the importing of DLNA devices.
I don't know the DLNA guidelines to say whether the current OSGi specification is well suited, but I guess DLNA is built on top of the "Non-standard vendor extensions" mechanism provided by UPnP, and such mechanism is not covered by OSGi, nor there is an alternative way to access/provide to the XML description of a UPnP Device. For example, the Felix UPnP implementation provides an interface to retrieve the URL of a UPnPDevice (or UPnPService) by UUID but it is not an standard solution.
So I think there are open issues it would be worth to discuss ;-) Is there a way to access to the DLNA guidelines/recommendation ? Can you provide us some pointer? Best regards, Francesco On 08/01/2011 20.47, Jackson, Bruce wrote:
I am the Chair of the DLNA Software Certification task force in DLNA, and have also produced a stack for DLNA based around the OSGi R4 UPnP specification. DLNA does not require anything more than is already defined in the existing OSGi specification, however, the current implementation of the driver has several problems which will result in non-compliance with DLNA specifications. In general, OSGi has defined interfaces for companions services rather than specific implementations, and its the implmentation that is the problem here. In our implementation of the OSGi R4 UPnP interfaces, we have used the approach set out by Patrik to allow the DLNA headers to be added to the device Dictionary. On 08/01/2011 03:31, "LongkerDandy"<[email protected]> wrote:Hi I'm not a expert on UPnP/DLNA. I hope OSGi could include/consider the DLNA implement, since it already have UPnP. And due to the fact we don't have a comprehensive open source Java UPnP/DLNA implement, we may need some work around. A bridge is just my quick thought ;D, I think the separation of different modules will be better. Patrick in (https://issues.apache.org/jira/browse/FELIX-2730) already point out some important facts. But I'm not sure the change to the xml generation would be enough. I didn't purchase the DLNA Guidelines, from what I see DLNA also define different discover method. And additional devices like device for mobiles. As a Java developer, I find it difficult to make a dlna app. Since lacking of decent library and dlna charge a fee for their document and test case. Thanks for your concern LongkerDandy On Fri, Jan 7, 2011 at 8:57 PM, Kai Hackbarth <[email protected]>wrote:Hi all, the OSGi Residential Expert Group is currently collecting requirements for the new specification. If you let us know the requirements, we can work on an update of the UPnP specification. Regards, Kai Am 07.01.2011 um 13:47 schrieb Francesco Furfari:Dear LongkerDandy, I think the right place to ask about updates of the UPnPSpecification is the OSGi Alliance ([email protected])or the OSGi Residential Expert Group. You are right, the OSGi UPnP specification hides a number of things(there are pro and cons).Few weeks ago there was a simple request about DLNA. Please look at Felix-2370 issue (https://issues.apache.org/jira/browse/FELIX-2730)Which are the missing features you would like to have in a customizedUPnP implementation?Please open or modify an issue and specify your requirements. Yes, the CyberlinkJava was not very active recently, but the bridgesolves only partially the problem, in any case (for DLNA) we need a review of the specification.I don't know Cling, how much distance there is from the Cyberlinkstack to easily design an abstraction layer.Another approach would be the modularization of all the UPnP stack, Imean the clear separation of the SOAP, GENA, and SSDP modules.Regards, Francesco On 06/01/2011 16.15, LongkerDandy wrote:Hi I'm not sure this is the right place to talk about this. I've been trying to write a Media Server, for a while. Already did some code with felix, (https://github.com/longkerdandy/chii2).I know OSGi has a UPnP standard and Felix has implement withCyberlinkJava.But seems the project is not very active, even it shipped with aMediaServer sample, it won't work. The fact is most devices/softwares are now compatible with DLNA. And they somehow buggy may need different headers or respond. OSGi hide all the UPnP stack, all I can get is a device interface. I think the idea behind that is a full UPnP stack supports all thedevices.But this may not work in real world, especially the UPnP stack is not actively maintained. Projects like PS3 Media Sever and Serviio is build from scratch. Now I'm trying Cling(http://teleal.org/projects/cling), another JavaUPnPstack. My thought is, DLNA is not as open as UPnP. OSGi may also support DLNA, and let us have a real OpenSource JavaDLNAimplementation. For now, can we make a bridge between UPnP driver and real UPnPstack.Thus make the UPnP stack switch-able. Regards LongkerDandy------------------------------------------------------------------------- ------------------------ Kai Hackbarth · Evangelist& Chair OSGi Residential Expert Group ProSyst Software GmbH D-50858 Cologne, Germany . Dürener Strasse 405 Tel. +49 (0)221 6604 410 · Fax +49 (0)221 6604 660 Mobile +49 (0)163 6604 410 · US Mobile +1-317-6039-264 http://www.prosyst.com · [email protected] ------------------------------------------------------------------------- ------------------------ stay in touch with your product. ------------------------------------------------------------------------- --------------------------------------------------------------------------------------------- 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]
