> 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
I have gone over the VCC and added an alternate way of passing
a uncomposed string to functions, as an alternative to STRING_LIST.
STRANDS is basically a STRING_LIST which gets stuffed into a
on-stack struct, so that more than one STRANDS argument can be
passed to a (VMOD-)function, something
> So from VCL, here is how we add VFPs:
>
> VOID add_vfp(VFP init, ENUM position = DEFAULT);
>
> VFP is "struct vfp" and any VMOD can return that, thus registering itself as
> a VFP. This contains all the callback and its input and output requirements.
>
> position is: DEFAULT, FRONT,
> - 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
Hi,
at first, I found Rezas concept appealing and there are some aspects which I
think we should take from it:
- take the protocol-vpfs v1f_* h2_body out of the game for vcl
- format specifiers:
- have:
(gzip), (plain) *1), (esi)
- ideas:
(br),
>> 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
>