After consideration and discussion, we decided to decline this feature request.
While we agree that it would be nice to have such a reference implementation, we are afraid it would take too much effort to make it truly generic and reusable. Seeing as these abstractions are usually built on top of a framework, maybe one of the Trusted Advisors or other 3rd parties can jump in and share something along those lines?
We really appreciate your input, declining the idea does not mean it didn't help us fine-tune the scope of DQMH and reconsider our strategy. Please keep those ideas coming 😉
It would be nice to have an example provided with the framework to demonstrate the implementation of a plugins architecture with DQMH :
Main Application (sources) <---> Plugin Interface (PPL) <---> Plugin (sources or PPL)
After consideration and discussion, we decided to decline this feature request.
While we agree that it would be nice to have such a reference implementation, we are afraid it would take too much effort to make it truly generic and reusable. Seeing as these abstractions are usually built on top of a framework, maybe one of the Trusted Advisors or other 3rd parties can jump in and share something along those lines?
We really appreciate your input, declining the idea does not mean it didn't help us fine-tune the scope of DQMH and reconsider our strategy. Please keep those ideas coming 😉
After consideration and discussion, we decided to decline this feature request.
While we agree that it would be nice to have such a reference implementation, we are afraid it would take too much effort to make it truly generic and reusable. Seeing as these abstractions are usually built on top of a framework, maybe one of the Trusted Advisors or other 3rd parties can jump in and share something along those lines?
We really appreciate your input, declining the idea does not mean it didn't help us fine-tune the scope of DQMH and reconsider our strategy. Please keep those ideas coming 😉