It looks like the latest commits just added the README. It looks much better; the README really clarifies how it should work.
I'm not sure exactly what a "plugin version" should do. It seems reasonably expectable that it will follow the same compatibility as the rest of the project. That is, it only breaks on major version revs. Minor versions might add hooks, though. It'd be nice if plugins could request the current version, in case they want to manage compatibility manually. But I suspect most won't bother, preferring to just keep it all up-to-date instead. I don't think the lack of a version api is a blocker, though. Are there any other thoughts? This is a few months old now and might could stand merging soon. On Mon, Oct 1, 2018 at 11:57 AM Eric Friedrich (efriedri) <[email protected]> wrote: > > I think some documentation/definitions would be great here as well. > > Whats a TO extension vs hook vs data? Are there any examples of how they > could be used? > > —Eric > > > > On Oct 1, 2018, at 1:44 PM, Rawlin Peters <[email protected]> wrote: > > > > Can we get a concise README.md on how to create a custom TO plugin > > that also links to the examples you've included in the PR? Also as new > > hooks are added, I think we'll need documentation for every hook to > > describe where in the request flow the hooks are called and the data > > available to each hook. > > > > Maybe since we're discussing a microservice plugin, you could lay out > > the basic high-level steps required to implement that in this plugin > > framework (not necessarily down to the nitty gritty details). > > > > Also, there's the question of the plugin interface versioning. How > > will we be versioning the plugin interface with guarantees to not > > break any plugins outside of our repo? Should we start out by tagging > > this plugin framework as experimental so that we don't really provide > > any compatibility guarantees while we're still working out the kinks? > > > > - Rawlin > > On Mon, Oct 1, 2018 at 10:38 AM Robert Butts <[email protected]> wrote: > >> > >> So, as we move Traffic Ops from Perl to Go, we need a way to write > >> extensions in Go, like we have in Perl. > >> > >> I wrote a plugin system for Go, modeled after the plugin frameworks in > >> Grove and Traffic Monitor, PR is here: > >> > >> https://github.com/apache/trafficcontrol/pull/2513 > >> > >> It's by no means complete, just like with Grove, we'll have to add > >> additional hooks and data as we find the need. But it works, it has basic > >> hooks, and includes some sample plugins. > >> > >> There was a question about microservices, if someone wants to write > >> extensions to their Traffic Ops as separate services, instead of built into > >> the same app. This framework allows that, it's easy to make a plugin that > >> calls out to another service when an endpoint is requested. > >> > >> Does anyone object to this PR? Could I get some +1's/-1's so we can get a > >> feel for whether people are OK with this PR being merged, and using this > >> plugin system for Traffic Ops going forward? > >> > >> Thanks, >
