-------- I've been pop'ing stack and come back down to this old topic.
The current hurdle is the cold/warm VCL events and how they get communicated to VMODS, directors and backends, and possibly other thingmajicks as well. It is very important to remember here, that backends is a subtype of directors, and that what the VMOD would do is create dynamic directors (which happen to be backends). Broadly speaking one avenue is to register all directors on a list of the VCL, and tell them warm/cold via this list. Right now we do not register directors anywhere, they are free standing objects and can come and go as they please. Making it mandatory to register all directors, just so we can send them events they probably don't care about seems rather silly. The alternative way is to make cold/warm events independent and provide a "call this function with this argument" registration mechanism for any interested temperature-sensitive vmod, object, backend or doodad. The disadvantage to this model is that there is no obvious or natural order to call these call-back functions. For instance we could waste time sending "COLD" to a bunch of backends which did individual registrations, on to see the vmod destroying them all when it gets the COLD event. Calling in first-registered-first-called order would probably avoid that scenario and give some kind of predictability. This ordering insecurity will require some thinking in some VMODs I can think of, but I can't think of any VMOD for which there isn't a reasonable solution. So I'm currently leaning towards this model. Backends should obviously register to get the events (in cache_backend_cfg), no matter if they are static or dynamic, so VMODs won't need to propagate the events. The third option is to make the vmod_priv the "base object" in compiled VCL, and tell those instead. This has a lot of merit from many angles, but I think that would have to wait for 5.0. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
