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: [oscar] Trouble with cleaning up on bundle stopping

Matrim Cauthon wrote: Nachricht
Our software will be released under LGPL or some Open-Source License, so if you are interested about it I could ask to our team to publish a preview
That would be great.
I ask to team and we decide to release it within this month
Why are you using threads
There are a lot of reasons:
 - Because I need to start-up HTTP Server for exporting and importing UPnP Device 
So you have an own http server which you start?
I could maybe understand that you need such thing for exporting but why importing?
Because even Control Point, that is the entity that we use to import device from UPnP Network, when subscribes to service should give to device a CallBack URI that should be http over tcp
I was under the impression you import these devices as OSGi services (and somehow wrap their functionality)
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?

 - 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)
(At the moment im in the design state but I didnt considered these things atm)
 - To speed up Exporting Process 
Thats the only reason I actually understand. I thought the the use  
 - Finally because I use CyberLink as UPnP Stack implementation 
 Okay, one has to use a UPnP Stack implementation as a UPnP BaseDriver is about monitoring UPnP Device and registers them with the FrameWork (and either way exporting and importing).
and why do you need to write into files?
 - Because to export  device I have to send XML file to describe it, and using CyberLink as PnP Stack Implementation I need use files
Okay, this one I figured out as soon as I sent my first mail, my appologies. 

Finally, I suppose that the use of files may be avoided, but the use of Thread is fundamental  
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?

Stefano Lenzi

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

Reply via email to:

Powered by MHonArc.

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