-
Notifications
You must be signed in to change notification settings - Fork 56
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
Consider Decoupling all but Memory Engine #109
Comments
Yes, that is an artifact from the old design. We'll be moving towards a broadway based plugin system for resource engines eventually. No need to build something new. Feel free to start up a fork / pull request. |
Seems somewhat relevant: |
Good call on using Broadway, re plugins I've written a small experimental library will comment on indexzero/broadway#34. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey Guys,
Love the general approach of resourceful, but just wondering why actual storage engines are implemented within the core library? Even though I primarily use CouchDB, it really just does make that much sense (to me) to have a library that handles abstract model definition implement storage adapters within the library itself?
This for me is somewhat reminiscent of earlier versions of winston which included an implementation of the loggly reporter and package dependencies to make it work.
Taking the example in the readme, I'd much rather do something like the following to wire up the storage engine:
You could additionally support your existing implementation by implementing an engine registry within resourceful, so that some initialization code such as below would result in the readme code working as is:
I'd certainly be happy to work on this kind of implementation if you felt that it was a direction that you wanted to take resourceful in.
Cheers,
Damon.
The text was updated successfully, but these errors were encountered: