You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by stephane frenot <st...@insa-lyon.fr> on 2007/06/28 10:42:08 UTC
Re: [Device Access service]
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 david.lindelof@adhoco.com
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
--
Stephane Frenot |
ARES INRIA / CITI, INSA-Lyon|mailto:stephane.frenot@insa-lyon.fr
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
--------------------------------------------------------------------------
RE: [Device Access service]
Posted by BOTTARO Andre RD-MAPS-GRE <an...@orange-ftgroup.com>.
We have to be clear on the terms used in the discussion. Otherwise, we do not understand each other. 5 entities are important in the specification for the examples to be explained:
- Driver: One driver knows one limited set of protocols and reifies (registers) the compliant devices into OSGi(tm) services in the registry. Usually, there is one base driver for one set of protocols (e.g. UPnP(tm)), or one driver for one device profile following one set of protocol (e.g. a UPnP(tm) printer).
- Base Driver: Thanks to some initial configuration, it is able to reify devices of a known protocol in the OSGi(tm) registry. See the X10 Base Driver (CM11) in Prosyst Smart Edition for example.
- Discovery Base Driver: Thanks to a discovery protocol belonging to the driver's given set of protocols, it is able to reify devices in the OSGi(tm) registry. See the standard OSGi(tm) UPnP Base Driver, which is implemented open source by Domoware.
- Refined Driver: A refined driver turns some registered devices with a matching type into refined ones and register them (e.g. turns UPnP(tm) devices with type=printer into UPnPPrinters)
- Device manager: responsible for the installed drivers, it reacts to the presence of devices in the registry and automatically downloads missing drivers. Driver selection is made thanks to Device locators and Device selectors. The selection of the best driver is made against registered device properties.
Further thoughts are to be read in: http://perso.orange.fr/andre.bottaro/papers/Bottaro-PervasiveServiceComposition-AINA07.pdf
--
André Bottaro <http://perso.orange.fr/andre.bottaro>
R&D Engineer - France Telecom Group
Tel. +33 4 76 76 41 03 - Fax. +33 4 76 76 45 57
e-mail: andre.bottaro@orange-ftgroup.com
-----Message d'origine-----
De : David Lindelöf [mailto:david.lindelof@adhoco.com]
Envoyé : mardi 3 juillet 2007 12:59
À : users@felix.apache.org
Objet : Re: [Device Access service]
Hi Stéphane,
Thanks for your clarifications. There are a couple of things I'm still
unsure about:
On Thu, 2007-06-28 at 10:42 +0200, stephane frenot wrote:
> 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.
Does this correspond roughly to what the OSGi specs call a "base
driver"? If I understand you correctly, this is something (not
necessarily a service, bundle nor even a program) that knows when a
device is connected to the platform. If it's through the serial port,
then chances are it is some initialization code that reads a
configuration file. If it is on the USB, chances are the base driver can
detect this automatically.
But then, how does this base driver know what device service to install?
Is the base driver supposed to come with service bundles for all kinds
of possible devices that might be connected? Who is responsible for
providing the device service implementations?
Suppose I have a serial port and USB port, to which I can connect two
different printers. As soon as the printers are connected, the base
drivers for each port are supposed to register a Printer device service,
aren't they? And this service will be provided by the same bundle, won't
it? So where does this bundle come from?
> 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.
What you describe sounds like the intuitive way to do it, but the OSGi
specs say that it is a Device Manager that is responsible for calling
the Driver.match() and Driver.attach() methods. So I do not really
understand at what time does the device service object get a reference
to the driver object.
> 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
I'm not sure I follow you. It's related to what was said above, but my
understanding is that the installation of a device service (any service
implementing the Device interface, or any service setting the
DEVICE_CATEGORY property) will cause the DeviceManager to start looking
for a driver. So it is not the responsibility of the Device service
object to find a driver, is it?
> 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.
What I would appreciate is some explanation of the device/driver example
in the specs. As far as I can see, the Device service object is never
"given" a reference to the driver directly.
Or put another way, the example seems to say that the Device service
object will never go looking for a driver, but instead will wait until a
SerialPort service gets registered in the framework---whether by a
driver or by any other bundle. Which sounds strange to me.
Do you know perhaps of any example code of a device/driver pair that I
could have a look at?
Kind regards,
--
--------------------------------------------------
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 david.lindelof@adhoco.com
url http://www.adhoco.com
weblog http://www.visnet.ch/smartbuildings/
--------------------------------------------------
There's nothing to writing. All you do is sit at a typewriter and open a vein.
-- Red Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: [Device Access service]
Posted by David Lindelöf <da...@adhoco.com>.
Hi Stéphane,
Thanks for your clarifications. There are a couple of things I'm still
unsure about:
On Thu, 2007-06-28 at 10:42 +0200, stephane frenot wrote:
> 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.
Does this correspond roughly to what the OSGi specs call a "base
driver"? If I understand you correctly, this is something (not
necessarily a service, bundle nor even a program) that knows when a
device is connected to the platform. If it's through the serial port,
then chances are it is some initialization code that reads a
configuration file. If it is on the USB, chances are the base driver can
detect this automatically.
But then, how does this base driver know what device service to install?
Is the base driver supposed to come with service bundles for all kinds
of possible devices that might be connected? Who is responsible for
providing the device service implementations?
Suppose I have a serial port and USB port, to which I can connect two
different printers. As soon as the printers are connected, the base
drivers for each port are supposed to register a Printer device service,
aren't they? And this service will be provided by the same bundle, won't
it? So where does this bundle come from?
> 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.
What you describe sounds like the intuitive way to do it, but the OSGi
specs say that it is a Device Manager that is responsible for calling
the Driver.match() and Driver.attach() methods. So I do not really
understand at what time does the device service object get a reference
to the driver object.
> 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
I'm not sure I follow you. It's related to what was said above, but my
understanding is that the installation of a device service (any service
implementing the Device interface, or any service setting the
DEVICE_CATEGORY property) will cause the DeviceManager to start looking
for a driver. So it is not the responsibility of the Device service
object to find a driver, is it?
> 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.
What I would appreciate is some explanation of the device/driver example
in the specs. As far as I can see, the Device service object is never
"given" a reference to the driver directly.
Or put another way, the example seems to say that the Device service
object will never go looking for a driver, but instead will wait until a
SerialPort service gets registered in the framework---whether by a
driver or by any other bundle. Which sounds strange to me.
Do you know perhaps of any example code of a device/driver pair that I
could have a look at?
Kind regards,
--
--------------------------------------------------
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 david.lindelof@adhoco.com
url http://www.adhoco.com
weblog http://www.visnet.ch/smartbuildings/
--------------------------------------------------
There's nothing to writing. All you do is sit at a typewriter and open a vein.
-- Red Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org