You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficcontrol.apache.org by GitBox <gi...@apache.org> on 2021/03/18 16:36:39 UTC

[GitHub] [trafficcontrol] rawlinp commented on pull request #5649: Add blueprint for Traffic Vault Interface

rawlinp commented on pull request #5649:
URL: https://github.com/apache/trafficcontrol/pull/5649#issuecomment-802093433


   >> - use the Traffic Ops API plugin system
   
   > So this wouldn't be a Plugin?
   
   Correct, it would not be a TO API plugin, as in it wouldn't totally override 22 different routes. Instead, it will be a `type TrafficVault interface`, of which a concrete struct (e.g. `RiakImpl` or `PostgresImpl`) will be assigned at startup time. I imagine this interface being hooked into the `APIInfo` object, similar to how the DB transaction is hooked into that as well. The interface methods (e.g. `Ping`, `DeleteDNSSECKeys`, etc.) will then be called within the route handlers we have today.
   
   > The main purpose of plugins is just to avoid merge conflicts
   
   Really the main purpose of plugins is to allow _proprietary implementations_ to override existing behavior while avoiding merge conflicts. With this interface design, the implementations could all be in their own file in order to avoid merge conflicts still. However, they wouldn't also have to be responsible for everything else I mention in the blueprint, just primarily the read/write integration with their chosen backend.
   
   So while it's not a "TO API plugin" per se, it's still a "pluggable" interface. We could call it a "Traffic Vault plugin" interface if you want, but it won't be a "Traffic Ops API plugin."


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org