jcnelson
commented
10 years ago This actually can't be achieved in a reasonable way, because:
- Drivers must have per-gateway secrets, sealed with the gateway's private key. Keeping drivers separate from gateways would complicate the generation and dissemination of per-gateway secrets, particular with regards to when/how we would need to update drivers, update gateways, and bind drivers to gateways.
- It's costly to determine the set of gateways whose certificate versions would need to change in response to a driver update.
- Separating the act of updating a driver and binding the driver to the gateway (triggering the reversioning) would force us to "re-bind" the driver on each update, as a separate step (whereas with the current approach, it's an atomic update to the gateway).
We can revisit this later, if need be, but for now this isn't really a problem. Users can set their own gateways' drivers, which is fine, and a single RG or AG can be instantiated multiple times anyway, reducing duplication.
Make a driver a first-class object in the MS, and make it bindable to a gateway. This avoids uploading duplicate drivers to the MS, just because they go onto different gateways.