Hello david, I worked on this, a few times ago, here some of my comments corresponding to my implementation (initially made for oscar).
Dear all,
Can someone help me shed light on the Device Access service? There are a couple of things I do not understand: 1) P. 50-51 of the OSGi Service Compendium R4 gives a example of a driver for a "WidgetDevice" device service. The code of the SerialWidgetDriver class seems to imply that before this class is instantiated, someone else has already registered a WidgetDevice service. Who is this someone else?
There are various kind of driver, one kind corresponds to bus drivers. (pcmcia, usb...) The one that registers the low end device is the bus driver. The bus device is manually started. For instance on unix, you start by hand the pcmcia controleur (device) which launches a pcmcia bus specific driver (Rico driver for instance). Then, when you insert a pcmcia card, the pcmcia driver register a card corresponding device, which triggers the card driver election and so on... 2) How does the implementation of the WidgetDevice service "know" which
driver to use? The SerialWidgetDriver.attach() method takes a ServiceReference as an argument, so there is no way for the driver to tell (say) WidgetServiceImpl "hi, you can use me to access the serial port now". All I see is that the SerialWidget class provides a serial access service to any bundle in the framework, not just to WidgetServiceImpl.
Each founded driver is installed. Then the device asks each driver a matching score. Each drivers answers and the highest answer is selected through the attach method. The idea is that you ask 3 locations to get 3 drivers from, for instance, proprietary, generic and open-source implementations. Then each location sends you some drivers; you install the various drivers, and invoke the match method for each driver, and the device selects the best score... If you have the proprietary driver it should have an highest score than the open-source for instance. The idea is that if the original remote site is out of order you get a replacement driver. This is odd because it seems to imply that even though
SerialWidgetDriver.attach() has been succesfully called, WidgetServiceImpl must still on his own discover a serial access service that it can use. 3) On p. 50, will the addingService() method be called upon instantiation, even though the WidgetDevice service is already registered (usually) when SerialWidget is instantiated?
?? I mean, this is the normal chain of events as I understand it:
- The Force registers a WidgetDevice service with its implementation WidgetServiceImpl. - The DriverLocator finds the SerialWidgetDriver, installs it, matches it against WidgetDevice, and calls the attach() method with a service reference to WidgetDevice as argument.
It is the device that triggers the matching process - SerialWidget is instantiated, passing a service reference to
WidgetDevice to its parent's (ServiceTracker) constructor. - Since WidgetDevice is already registered, nothing else happens and addingService() is not called. And no serial access service is registered by SerialWidget. WidgetDeviceImpl is left hanging in memory space. I'd really appreciate any help some kind soul could offer me on this topic.
I'm not sure to understand the last part. One element to see is that the system could continuously look for better drivers. So new driver (with better matching method) can be found during run-time. Regards /stephane --
-------------------------------------------------- David Lindelöf Product Developer Adhoco AG Technopark Jagerstrasse 2 8406 Winterhur tel +41-52-203.2903 mob +41-79-415.6641 fax +41-52-203.2904 e-mail [EMAIL PROTECTED] url http://www.adhoco.com weblog http://visnet.ch/smartbuildings/ -------------------------------------------------- Hacker's Law: The belief that enhanced understanding will necessarily stir a nation to action is one of mankind's oldest illusions. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Stephane Frenot | ARES INRIA / CITI, INSA-Lyon|mailto:[EMAIL PROTECTED] Bat. Léonard de Vinci |http://ares.insa-lyon.fr/~sfrenot/ 21 av Jean Capelle | ICQ:643346 (et oui !) F-69621 Villeurbanne Cedex |+33 472 436 422/+33 617 671 714 --------------------------------------------------------------------------
