On Mon, Jun 23, 2014 at 10:13 AM, Poul-Henning Kamp <[email protected]> wrote: > > We talked a bit about what vmod_std should contain at the VDD in > Stockholm and the consensus-ish-thingie was that generally useful > facilities could go in there, as long as they don't drag in any > 3rd party libraries.
The querystring module doesn't drag any dependency, so you could turn this into a native module and replace its `sort` function by the boltsort module's function. You would need to remove the Varnish 3 stuff (using cpp to deal with differences) and make it conform to your coding standards. Also this function uses the request's workspace (which is fine to me) but it's still not part of VRT despite ABI rules being relaxed with major/minor compatibility. I have plans for the querystring modules (new functions, and functions replaced by objects) but if you were to include it in the main tree, I would continue maintenance. I'd maintain the 3.0 vmod as I do today and send you relevant patches. > Functions for washing headers etc are certainly in that category. In this case I'd rather not put "everything" in the std module, like you did with the directors. The cookie module would be a good candidate too for instance. But I agree, that you'd need a significant amount of related functions to put them in their own module, and you probably don't want to include too many of them. Best Regards, Dridi > -- > 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 _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
