-------- In message <cabovn9dm9be45qkbhtsbca5u6jnwncfgk0qnav1ch3xmrn4...@mail.gmail.com> , Dridi Boukelmoune writes: >> VCL_DelBackend is declared in $include_dir/cache/cache_backend.h, so >> it's available to a VMOD, and there's no indication that it's "not >> supposed to" be used. I've suspected that there are things in >> $include_dir that aren't really meant to be public, but if we're >> serious about that, and if Varnish is liable to crash if a VMOD does >> use them, then perhaps we should separate out the non-public >> interfaces. Or at least document them as non-public -- we have that in >> the *_int.h includes in vapi, for example. > >If it were up to me I'd simply remove everything that doesn't start >with VRT_, except of course symbols from libvarnish* and related data >structures :)
No. The plan here is to offer two levels of API: If you stick with VRT functions, porting your VMOD should be piece of cake. If you need to do something more advanced, you get what you ask for. >I don't even know how you would delete the backend without breaking >the type system. That is *exactly* what I'm talking about. When VCL types have underlying C types that require manual memory management (ie: BLOB, BACKEND ...) we need to do manual memory management, and we need to have a coherent and *understandable* architecture for it. -- 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
