There are two main options for how to work around issues with non-PnP buses (serial port, irDA, etc):

1)·Have the driver poll

• This polling thread is started when the driver loads and continues to poll until the driver is unloaded.
• It provides a PnP-like experience since the driver can send an event to Connection Center (and all listening apps) when the device arrives and when it leaves.
• This is the typical solution most vendors implement.

2) Have the driver be request-driven (i.e. no polling)

• When a request comes into the driver for data (e.g. an application is asking “How many Glucose Readings do you have?”) the driver attempts to talk to the device.  If the device responds, then the driver grabs the data and fulfills the request.  If the device does not respond, then the driver assumes the device is not currently plugged in and returns no items.
• This is safer than polling, but has two main drawbacks:
• The user experience is not as good because the user has to initiate the action (e.g. Browse the device in My Computer, or Click “Upload Data to HealthVault” in Connection Center etc.).
• The driver needs to implement some logic about when it “refreshes” data in its cache (i.e. since it’s not polling, it doesn’t know when the device leaves and comes back with new data.  Calling into the device on every request is usually not an option for performance reasons so some form of caching is usually employed).

Based on your needs, you may implement either solutions.