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: [EMAIL PROTECTED]
-----Message d'origine-----
De : David Lindelöf [mailto:[EMAIL PROTECTED]
Envoyé : mardi 3 juillet 2007 12:59
À : [email protected]
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 [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
