<div dir="ltr">> <span style="font-size:12.8px">take the protocol-vpfs v1f_* h2_body out of the game for vcl</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">I wonder how we would even guarantee that this algorithm ever terminates.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">I think the position should be mapped closer to HTTP semantics</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">--<br>Reza Naghibi<br>Varnish Software</div></div></div>
<br><div class="gmail_quote">On Mon, Dec 18, 2017 at 8:58 AM, Dridi Boukelmoune <span dir="ltr"><<a href="mailto:dridi@varni.sh" target="_blank">dridi@varni.sh</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> - format specifiers:<br>
><br>
> - have:<br>
><br>
> (gzip), (plain) *1), (esi)<br>
><br>
> - ideas:<br>
><br>
> (br), (buffertext) *2)<br>
><br>
> esi being a format which can contain gzip segments, but that's would<br>
> be opaque to other vfps<br>
</span>[...]<br>
<span class="">> *1) "(text)" in reza's concept<br>
<br>
</span>Or "identity" to match HTTP vocabulary.<br>
<span class=""><br>
> *2) not sure if this is a good idea, maybe multi segment regexen are the better<br>
> idea<br>
<br>
</span>For a lack of better place to comment, in my previous message I put<br>
`content` before `assembly`. On second thought it should be the other<br>
way around, otherwise <esi> tags break the content type.<br>
<span class="HOEnZb"><font color="#888888"><br>
Dridi<br>
</font></span></blockquote></div><br></div>