Re: VFP and VDP configurations

2017-12-18 Thread 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

VCL_STRANDS

2017-12-18 Thread Poul-Henning Kamp
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

Re: VFP and VDP configurations

2017-12-18 Thread Dridi Boukelmoune
> 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,

Re: VFP and VDP configurations

2017-12-18 Thread Dridi Boukelmoune
> - 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

Re: VFP and VDP configurations

2017-12-18 Thread Nils Goroll
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),

Re: VFP and VDP configurations

2017-12-18 Thread Dridi Boukelmoune
>> 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 >