Main driver interface for a key storage location.
Drivers are concrete implementations of a {@link Store}. In addition to implementing this interface, the instantiatable driver class must be annotated with {@link DriverInfo}, provide a public constructor with no arguments and implement {@link ReadableDriver} and/or{@link WritableDriver} depending on the operations supported. For example,a driver that only allows importing of Keys would only implement {@link ReadableDriver}. The {@link WrappingDriver} interface should be implemented for drivers that support wrapping/unwrapping of Keys.
When instantiated, {@link #initialize(K2Context)} will be invoked on thedriver to provide the context of the current K2 session. After a successful initialization, {@link #open(URI)} will be called to actually allocateresources for performing storage operations on the specified storage address. This method may throw {@link IllegalAddressException} if the address is notrecognized by the driver. Finally, {@link #close()} will be called to freeresources, after the user has performed the storage operations. Note that it is NOT safe to allocate resources before {@link #open(URI)} is called,e.g. during construction or on initialize.
Drivers need not be concerned with thread safety, or methods invoked when they are not supported, or methods invoked when {@link #open(URI)} has notbeen called, or methods invoked when {@link #close()} has been called. The{@link Store} wrapper will manage all access to the driver by ensuring thatcalls are synchronized, methods are not invoked when inappropriate, etc.
A note about open/close and network-based stores: It is possible for the network connection to drop after the driver is opened. However, the driver must not implicitly close the store in this event. As long as the store is still open, the connection should be reattempted.
@author darylseah@gmail.com (Daryl Seah)