Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attachment provider #71

Open
StephenRedd opened this issue Jun 9, 2017 · 0 comments
Open

Attachment provider #71

StephenRedd opened this issue Jun 9, 2017 · 0 comments
Labels

Comments

@StephenRedd
Copy link
Member

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant