VIP9: Expand VCL object support

Synopsis

Currently objects are limited to global objects which have a lifetime of the entire VCL. This VIP is to have objects which can be created during the request and their scope is limited to that request. When the request is done, the objects are fini'ed.

Original VIP9 date: April 25, 2016

Updated VIP9 date: November 18, 2019

See also: VIP9B

Why?

By allowing VMOD objects to live in the request scope, we can easily bring in OO style types and high level programming constructs to VCL. For example: integers, strings, doubles, lists, hash tables, encryption, encoding, anything and everything.

How

Here is a VCL snippet which compiles and works with the patch [0] and uses a new libvmod_types [1].

vcl 4.1;

import types;

sub vcl_recv
{
  //new req scoped objects
  new slocal = types.string("Request scoped string");
  new s2 = types.string("request string two");
  new count = types.integer(1);
}

sub vcl_backend_fetch
{
  //new bereq scoped objects
  new sbe = types.string("berequest string v1");
  set bereq.http.sbe = sbe.value();

  sbe.set("berequest string v2");
  set bereq.http.sbe2 = sbe.value();
}

sub vcl_deliver
{
  //referencing objects
  set resp.http.X-slocal = slocal.value();
  set resp.http.X-slocal-length = slocal.length();

  count.increment(10);
  set resp.http.count = count.value();
}

Notes

This patch is by no means the final product. Rather, its meant to show how simple a request scoped object implementation can be and to start building consensus on what the final product should look like.

Here is a list of things that need to be done:

• Iron out priv_task rough edges. If this were to move forward, we should introduce a special struct which is made for objects and can be shared between local and global scopes. Currently there are 2 different implementations in play in this patch. Making this better could possibly include introducing breaking changes to objects.

• Address uninitialized objects. Its always going to be possible to exit a sub early and leave an object uninitialized. There are ways to detect this and error out.

• We can address using the top scope by using a (top) cast: new (top) myvar = vmod.object(). However, every example I try to think of where this would be useful turns out to be not actually useful. So it might make sense to drop this requirement while knowing this is technically possible if we want to revisit it in the future.

[-1] 2016 https://github.com/rezan/varnish-cache/commit/b547bd9ad2fca9db1ef17ee73b8e9b7df9950c34

[0] 2019 https://github.com/varnishcache/varnish-cache/compare/master...rezan:req_objects

[1] https://github.com/rezan/libvmod-types