VFP and VDP configurations

[Reza Naghibi]

> take the protocol-vpfs v1f_* h2_body out of the game for vcl

Those will be builtin on the delivery side. So I didnt really dive into
VDPs, but it works similar to VFPs in that the client expects a certain
kind of response, so its upto the VDP chain to produce a matching output.
So if the client wants an H2 range response gzipped, then that chain needs
to be put together starting at resp in the stevedore and ending at the
client. So its different, but the same structure and rules apply.

> I wonder how we would even guarantee that this algorithm ever terminates.

Right, since processors can modify the chain as its being built and change
things mid flight, this could definitely happen. So the only thing to do
here is have a loop counter and break out after a certain amount of
attempts at creating the best fit chain. Its kind of like a graph search
where when you hit every node, the node can change the graph ahead of you
or optionally move you back positions. So in this case, its very possibly
to get stuck in an unavoidable loop.

> I think the position should be mapped closer to HTTP semantics

I think this makes too many assumptions? For example, where would security
processors go? Knowing what I know about whats possible with these things,
I think the processor universe might be bigger than the 4 categories you
listed out.

I think this brings up an important point, which is that for us to be
successful here, we really need to bring forward some new processors to be
our seeds for building this new framework. This will drive the requirements
that we need. I think there will be a lot of uncertainty if we build this
based on theoretical processors. I think its alright if these new
processors are simple and our new framework starts off simple as well. This
can then evolve as we learn more. For me, I have written a handful of
processors already, so a lot of what I am proposing here comes from past
experience.



--
Reza Naghibi
Varnish Software

On Mon, Dec 18, 2017 at 8:58 AM, Dridi Boukelmoune <dridi at varni.sh> wrote:

> > - format specifiers:
> >
> >         - have:
> >
> >           (gzip), (plain) *1), (esi)
> >
> >         - ideas:
> >
> >           (br), (buffertext) *2)
> >
> >         esi being a format which can contain gzip segments, but that's
> would
> >         be opaque to other vfps
> [...]
> > *1) "(text)" in reza's concept
>
> Or "identity" to match HTTP vocabulary.
>
> > *2) not sure if this is a good idea, maybe multi segment regexen are the
> better
> >     idea
>
> For a lack of better place to comment, in my previous message I put
> `content` before `assembly`. On second thought it should be the other
> way around, otherwise <esi> tags break the content type.
>
> Dridi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20171218/9c582823/attachment-0001.html>