ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google


Mail Archive Home | oscar List | July 2004 Index

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

Re: AW: AW: AW: [oscar] Trouble with cleaning up on bundle stopping


Matrim Cauthon wrote:
Nachricht
Hello,
*snip* 
 It's true but there are a lot of detail to cover, and some are not treat by OSGi specification, like:

 - You have UPnPDevice A that contains UPnPDevice B exported to UPnP Network, what should we done when B is unregistered? Should base driver unexport whole device? Or Should base driver rebuild a new device to export? Or Should base driver simply stop to notify the existences of the embedded device? 
 
 By UPnPDevice you mean you have somehow registered a device with the framework under a UPnPDevice interface using the export property?
 But I see what you mean, what solution do you prefer?
We haven't decide yet... all the way are open... Maybe the way that we will implement is to stop exporting whole device as soon as some children disappears...
If you found other uncovered details, could you tell me?

 - And there are other

 - Because I need to check for expired imported device 
 - Because I need to monitor SSDP packet 
 
Shouldn't take the Stack implementation take care of it?
Im really confused ..
Sure, in fact most of all the Thread are used by UPnP Stack Implementation and are: the HTTP Server, SSDP Server, Exipring Check. The only thread needed on top of  Stack are need:
 - to speed up exporting process
 - to avoid OSGi FrameWork hang up
 - to respect UPnP Base Driver specification (see dispatching notification to UPnPEventListener) 
 
Okay.
Are there any known issues why and when the framework could hang up?
For example, if you entangle yourself with deadlock  while you are processing a serviceChanged framework Call-Back.
For now I was about (at the BaseDriver Activator start) instantiating a UPnP Control Point which actually monitors UPnP Devices in the network and register them accordingly with the framework.
Is this a wrong approach?
It's the same approach that we use to importing. Which UPnP Stack implementation are you using? 
 
I'm currently playing around with the Siemens UPnP Stack implemention and get some very basic stuff running since I'm alone its far from perfect =)
Can send me a link?
 
Is there something like a general road map how to export?
In  few words, what we do is:
1 -  Monitor for UPnPDevice with the correct property value
2 - When a UPnPDevice is registered, if all it's UPnPDevice child are registered
    2.1 - Create all XML and Icon file from the property of the ServiceReference
    2.2 - Build a Device using your UPnP Stack implementation with your XML
    2.3 - Bind implementation of the action to the real UPnPDevice service object

P.S.: How do you manage data type to bind action?
(Only OSGi registered service with the export property will be exported, right?
Yes, and with the correct Property value
So the base driver have to watch the service registered and take actions accordingly.) 
 
 
I still have some basic flaws.
Under which scenario would another service request a UPnPDevice (service)?
When a Control Point is build on top of OSGi FrameWork :-)
When someone build a Driver to expose a better interface than UPnPDevice
 
Bye,
Stefano Lenzi
 
 
Thank you for your patience,
Mat. 



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

Reply via email to:

Powered by MHonArc.

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