Re: RFC DQ Pluggability
Thanks Aaron, Put in a few changes to the document to make the prototypes "pop" a little bit more. A few suggestions / talking points though:
I think it would be useful if this at least included the mamaTransport that has just been created.
It reads like setStale will represent something related to the staleness but it's not clear what possible values they may have. I also wonder if the use of mamaTransportEvent might be more useful here? Is it also feasible that this may not be necessary at all if the postCreateHook could set up a standard transport callback? I'm not sure about what's meant by the Plugin Changes section when it talks about the overriding of the default dq plugin in the plugin code. Instead might it be more straightforward if: 1. Additional plugins for dq could simply be loaded and live alongside each other. On-hook the plugin can then decide if it wants to set itself up based on its own configuration standards. 2. The "default" dq plugin could do something similar and decide itself if it wants to take action. This would make it more like a standard plugin rather than a special case for DQ. 3. The transportCreateHook for the dq plugin could then *itself* check a property *there* or on init to decide whether or not it should take action on this transport for the bridge as updates are fired. Cheers, Frank
On Wed, Jan 31, 2018 at 11:30 AM, Aaron Sneddon <asneddon@...> wrote:
|
|