Attachment provider #71
Description
Currently, the history mechanisms assume that attachment serialization and storage (if enabled) must be managed by the history store itself.
It would be nice if attachment handling (and possibly body content handling too) were a separate service coordinated by the history store, rather than an intrinsic part of the history store itself. This way, the consuming application could provide an alternate attachment store (like a file system store).
- Ability to provide an implementation of an attachment handler to any history store
- History store would delegate serialization and storage to the handler
- History packages would provide a native attachment handler for storing the attachment with the rest of the history data (in the DB for the EF SQL package)
- Customers and other packages could provide alternate handlers (like a file system handler) instead.