Hi, I will try to wrap up the model I was suggesting on IRC.
For starters, I refer to dynamic backends as *native* backends (ones you can see in varnishstat) managed by a VMOD instead of VCL. We agreed that even though a VMOD lifespan can exceed the lifespan of a VCL, a dynamic backend cannot survive its VCL. For this reason I find VCL objects compelling for VMOD writers, because VMODs merely allocate/free objects, while VCLs manage/use them. One wouldn't be required to tie dynamic backends to an object, but they would have to keep track of the per-VCL resources themselves. For cold/warm state, I'm all for passing the events to VMODs (if the event specifies which VCL is sending the event) or even better to objects (since they *are* managed by a VCL). Allowing VMODs to follow the cold/warm state on their own resources is interesting[1]. Putting all this together: - VCLs own static backends - VMODs should own dynamic backends - Objects are the best candidates to manage dynamic backends - VCLs should only send events to things it manages: static resources, objects (not sure about VMODs) - VMODs *can* propagate events to backends Of course the last bullet point means more work for VMOD writers, but in most cases it's probably just walking a data structure and forwarding the event to each item. It also has the advantage of not introducing order issues, and allowing VMODs to override the VCL warm/cold state policy. The first bullet point on the other hand means only *minor* modifications are needed in Varnish to enable that. Best Regards, Dridi [1] but what happens on vmod_tour, stays on vmod_tour On Thu, Jun 11, 2015 at 11:16 PM, Poul-Henning Kamp <[email protected]> wrote: > -------- > > I've been pop'ing stack and come back down to this old topic. _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
