From dridi at varni.sh  Mon Feb  4 19:26:08 2019
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Mon, 4 Feb 2019 20:26:08 +0100
Subject: VMOD havoc generating patch
In-Reply-To: <84471.1548680044@critter.freebsd.dk>
References: <84471.1548680044@critter.freebsd.dk>
Message-ID: <CABoVN9BOLePiYW3tVLVj1vK6fOn23YkHw2znpCTvf936sL7Tcw@mail.gmail.com>

On Mon, Jan 28, 2019 at 1:55 PM Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> Ticket 2810 is about the names generated by vmodtool and vcc, and
> while there is a good intellectual argument for getting it right,
> I am a little bit worried about how much havoc that causes.
>
> This is a WIP patch headed in that direction, and I would like to
> hear input from VMOD writers.
>
> Ideally with this stuff finished, VMOD writers can version their
> vmods using $Prefix and you will then be able to import multiple
> different versions of the same VMOD in the same VCL.  Not sure that
> is a good thing to do, but it proves that the name-space issue is
> solved.
>
> See the changes to the in-tree vmods for how this will look for you.

I waited until my weekly CI against master would choke on this change,
and it's very easy to support both before and after if your baseline
is 6.0, which is more than fine since 4.1 only has a couple months to
live:

    #include "vcc_$VMOD_if.h"

    /* Varnish < 6.2 compat */
    #ifndef VPFX
     #define VPFX(a) vmod_ ## a
     #define VARGS(a) vmod_ ## a ## _arg
     #define VENUM(a) vmod_enum_ ## a
    #endif

I didn't try on a vmod with a $Prefix stanza, but I'm sure it can be
helped if that snippet is not enough.

Dridi

From phk at phk.freebsd.dk  Mon Feb  4 19:30:18 2019
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 04 Feb 2019 19:30:18 +0000
Subject: VMOD havoc generating patch
In-Reply-To: <CABoVN9BOLePiYW3tVLVj1vK6fOn23YkHw2znpCTvf936sL7Tcw@mail.gmail.com>
References: <84471.1548680044@critter.freebsd.dk>
 <CABoVN9BOLePiYW3tVLVj1vK6fOn23YkHw2znpCTvf936sL7Tcw@mail.gmail.com>
Message-ID: <92757.1549308618@critter.freebsd.dk>

--------
In message <CABoVN9BOLePiYW3tVLVj1vK6fOn23YkHw2znpCTvf936sL7Tcw at mail.gmail.com>, Dridi Boukelmoune writes:
>On Mon, Jan 28, 2019 at 1:55 PM Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

>I waited until my weekly CI against master would choke on this change,
>and it's very easy to support both before and after if your baseline
>is 6.0, which is more than fine since 4.1 only has a couple months to
>live:
>
>    #include "vcc_$VMOD_if.h"
>
>    /* Varnish < 6.2 compat */
>    #ifndef VPFX
>     #define VPFX(a) vmod_ ## a
>     #define VARGS(a) vmod_ ## a ## _arg
>     #define VENUM(a) vmod_enum_ ## a
>    #endif
>
>I didn't try on a vmod with a $Prefix stanza, but I'm sure it can be
>helped if that snippet is not enough.

Yes, that would go a long way towards compatibility.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dridi at varni.sh  Mon Feb  4 21:25:19 2019
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Mon, 4 Feb 2019 22:25:19 +0100
Subject: VMOD havoc generating patch
In-Reply-To: <92757.1549308618@critter.freebsd.dk>
References: <84471.1548680044@critter.freebsd.dk>
 <CABoVN9BOLePiYW3tVLVj1vK6fOn23YkHw2znpCTvf936sL7Tcw@mail.gmail.com>
 <92757.1549308618@critter.freebsd.dk>
Message-ID: <CABoVN9AUh=DHA5Xt38=bJMAfOGZ=q1pooxG1wH_2UBkVWnYcrA@mail.gmail.com>

On Mon, Feb 4, 2019 at 8:30 PM Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> --------
> In message <CABoVN9BOLePiYW3tVLVj1vK6fOn23YkHw2znpCTvf936sL7Tcw at mail.gmail.com>, Dridi Boukelmoune writes:
> >On Mon, Jan 28, 2019 at 1:55 PM Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> >I waited until my weekly CI against master would choke on this change,
> >and it's very easy to support both before and after if your baseline
> >is 6.0, which is more than fine since 4.1 only has a couple months to
> >live:
> >
> >    #include "vcc_$VMOD_if.h"
> >
> >    /* Varnish < 6.2 compat */
> >    #ifndef VPFX
> >     #define VPFX(a) vmod_ ## a
> >     #define VARGS(a) vmod_ ## a ## _arg
> >     #define VENUM(a) vmod_enum_ ## a
> >    #endif
> >
> >I didn't try on a vmod with a $Prefix stanza, but I'm sure it can be
> >helped if that snippet is not enough.
>
> Yes, that would go a long way towards compatibility.

It seems incomplete though, currently the $Prefix is applied all over
the place and the VPFX macro isn't used for function names. Is that
still work in progress?

Dridi

From phk at phk.freebsd.dk  Mon Feb  4 21:29:02 2019
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 04 Feb 2019 21:29:02 +0000
Subject: VMOD havoc generating patch
In-Reply-To: <CABoVN9AUh=DHA5Xt38=bJMAfOGZ=q1pooxG1wH_2UBkVWnYcrA@mail.gmail.com>
References: <84471.1548680044@critter.freebsd.dk>
 <CABoVN9BOLePiYW3tVLVj1vK6fOn23YkHw2znpCTvf936sL7Tcw@mail.gmail.com>
 <92757.1549308618@critter.freebsd.dk>
 <CABoVN9AUh=DHA5Xt38=bJMAfOGZ=q1pooxG1wH_2UBkVWnYcrA@mail.gmail.com>
Message-ID: <93429.1549315742@critter.freebsd.dk>

--------
In message <CABoVN9AUh=DHA5Xt38=bJMAfOGZ=q1pooxG1wH_2UBkVWnYcrA at mail.gmail.com>, Dridi Boukelmoune writes:
>On Mon, Feb 4, 2019 at 8:30 PM Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

>It seems incomplete though, currently the $Prefix is applied all over
>the place and the VPFX macro isn't used for function names. Is that
>still work in progress?

You mean the in-tree vmods ?

Yes, I only applied the necessary macros to make things work again,
in order to highlight that you dont *have* to use the macros to
write/port a VMOD to the new world order.

After the dust has settled and march release is out, I think we
should fully macro-ize the in-tree VMODS, but if you guys think
it is a better idea to go the full step now, I'm fine with that.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dridi at varni.sh  Tue Feb  5 07:16:35 2019
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Tue, 5 Feb 2019 08:16:35 +0100
Subject: VMOD havoc generating patch
In-Reply-To: <93429.1549315742@critter.freebsd.dk>
References: <84471.1548680044@critter.freebsd.dk>
 <CABoVN9BOLePiYW3tVLVj1vK6fOn23YkHw2znpCTvf936sL7Tcw@mail.gmail.com>
 <92757.1549308618@critter.freebsd.dk>
 <CABoVN9AUh=DHA5Xt38=bJMAfOGZ=q1pooxG1wH_2UBkVWnYcrA@mail.gmail.com>
 <93429.1549315742@critter.freebsd.dk>
Message-ID: <CABoVN9DZkhCtchRvBzh+zP0jwheex1=WVFdOMC7NJ-MfFgyiGA@mail.gmail.com>

On Mon, Feb 4, 2019 at 10:29 PM Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> --------
> In message <CABoVN9AUh=DHA5Xt38=bJMAfOGZ=q1pooxG1wH_2UBkVWnYcrA at mail.gmail.com>, Dridi Boukelmoune writes:
> >On Mon, Feb 4, 2019 at 8:30 PM Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> >It seems incomplete though, currently the $Prefix is applied all over
> >the place and the VPFX macro isn't used for function names. Is that
> >still work in progress?
>
> You mean the in-tree vmods ?

No, I mean when I look at the generated vcc_$VMOD_if.h, I see many
occurrences of the $Prefix that are not guarded by VPFX() macros.

> Yes, I only applied the necessary macros to make things work again,
> in order to highlight that you dont *have* to use the macros to
> write/port a VMOD to the new world order.

Right, but it's very convenient to maintain 6.0 source compatibility :3

> After the dust has settled and march release is out, I think we
> should fully macro-ize the in-tree VMODS, but if you guys think
> it is a better idea to go the full step now, I'm fine with that.

The in-tree C files don't need to be macro-ized, I was mostly
concerned by the if.h file generated by vmodtool. But even that
shouldn't matter too much.

Taking my snippet and applying s/vmod/$Prefix/ to it is probably enough.

Dridi

From phk at phk.freebsd.dk  Tue Feb  5 09:17:05 2019
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 05 Feb 2019 09:17:05 +0000
Subject: VMOD havoc generating patch
In-Reply-To: <CABoVN9DZkhCtchRvBzh+zP0jwheex1=WVFdOMC7NJ-MfFgyiGA@mail.gmail.com>
References: <84471.1548680044@critter.freebsd.dk>
 <CABoVN9BOLePiYW3tVLVj1vK6fOn23YkHw2znpCTvf936sL7Tcw@mail.gmail.com>
 <92757.1549308618@critter.freebsd.dk>
 <CABoVN9AUh=DHA5Xt38=bJMAfOGZ=q1pooxG1wH_2UBkVWnYcrA@mail.gmail.com>
 <93429.1549315742@critter.freebsd.dk>
 <CABoVN9DZkhCtchRvBzh+zP0jwheex1=WVFdOMC7NJ-MfFgyiGA@mail.gmail.com>
Message-ID: <85020.1549358225@critter.freebsd.dk>

--------
In message <CABoVN9DZkhCtchRvBzh+zP0jwheex1=WVFdOMC7NJ-MfFgyiGA at mail.gmail.com>, Dridi Boukelmoune writes:


>No, I mean when I look at the generated vcc_$VMOD_if.h, I see many
>occurrences of the $Prefix that are not guarded by VPFX() macros.

The VPFX/VARGS/VENUM macros are mostly intended as convenience for the
files the vmod-author writes.

I didn't VPFX the prototypes to not _force_ people to use the VPFX
in their code if they dont want to, but if the consensus is that
we should be pushing VPFX() usage, changing it is just stylistic.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dridi at varni.sh  Tue Feb  5 09:54:03 2019
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Tue, 5 Feb 2019 10:54:03 +0100
Subject: VMOD havoc generating patch
In-Reply-To: <85020.1549358225@critter.freebsd.dk>
References: <84471.1548680044@critter.freebsd.dk>
 <CABoVN9BOLePiYW3tVLVj1vK6fOn23YkHw2znpCTvf936sL7Tcw@mail.gmail.com>
 <92757.1549308618@critter.freebsd.dk>
 <CABoVN9AUh=DHA5Xt38=bJMAfOGZ=q1pooxG1wH_2UBkVWnYcrA@mail.gmail.com>
 <93429.1549315742@critter.freebsd.dk>
 <CABoVN9DZkhCtchRvBzh+zP0jwheex1=WVFdOMC7NJ-MfFgyiGA@mail.gmail.com>
 <85020.1549358225@critter.freebsd.dk>
Message-ID: <CABoVN9D2nPWGxy6N0m7NYNA-fBoZyHf1upruOcxib4mHEoxGsQ@mail.gmail.com>

> >No, I mean when I look at the generated vcc_$VMOD_if.h, I see many
> >occurrences of the $Prefix that are not guarded by VPFX() macros.
>
> The VPFX/VARGS/VENUM macros are mostly intended as convenience for the
> files the vmod-author writes.

Ack.

> I didn't VPFX the prototypes to not _force_ people to use the VPFX
> in their code if they dont want to, but if the consensus is that
> we should be pushing VPFX() usage, changing it is just stylistic.

I will leave it to $Prefix users that need to support both 6.0 and the
new 6.2 vmodtool to leave an opinion here. I don't use the $Prefix
stanza.

Thanks,
Dridi

From phk at phk.freebsd.dk  Mon Feb 11 22:59:23 2019
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 11 Feb 2019 22:59:23 +0000
Subject: tabular CLI output proof of concept hack
Message-ID: <84707.1549925963@critter.freebsd.dk>

While looking at #2896 it bothered me how much code we spend on
text-processing the CLI output.

Since we now have -j for machine-readable output, it would make
sense to make the non-j output more human-friendly, and avoid some
of all that text-processing at the same time.

I threw together the attached proof-of-concept hack, which adds
a central function to figure out how wide the columns of tabular
output should be, and to reformat it thusly.

The idea is that the CLI code, in this case vcl.list sticks
some ASCII control-chars in the vsb to mark the columns, which then
autosize once all the output is ready, rather than have all the
"lets set this column width to 28 ? 45 ? 51?" guesswork.

In the hack I have also added column headers for nicer output
so that it looks like this:

	Status Readiness Ref Name        
	====== ========= === ====         
	active auto/warm 1   vcl1          

(Ignore the amount of space/padding etc, that's for later)

I kind of like it.

But I am also seriously wondering if we should go even further and
have varnishd *only* produce JSON output, and leave the render-for-humans
aspect to varnishapi or even varnishadm.

Comments welcome...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: _.patch
Type: text/x-diff
Size: 4522 bytes
Desc: _.patch
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20190211/18e1cbb2/attachment.bin>

From dridi at varni.sh  Tue Feb 12 08:59:14 2019
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Tue, 12 Feb 2019 09:59:14 +0100
Subject: tabular CLI output proof of concept hack
In-Reply-To: <84707.1549925963@critter.freebsd.dk>
References: <84707.1549925963@critter.freebsd.dk>
Message-ID: <CABoVN9DEjdVU1XL1QWwn8DycHSfcVoLdRB-z=H5jUeEPy4M91A@mail.gmail.com>

> But I am also seriously wondering if we should go even further and
> have varnishd *only* produce JSON output, and leave the render-for-humans
> aspect to varnishapi or even varnishadm.

Ideally implement it in libvarnish.a and expose it in libvarnishapi,
with a way for varnishadm to specify a window size in interactive
mode. This way varnishd -d will be able to produce the plain text
output.

Dridi

From phk at phk.freebsd.dk  Tue Feb 12 11:22:40 2019
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 12 Feb 2019 11:22:40 +0000
Subject: tabular CLI output proof of concept hack
In-Reply-To: <CABoVN9DEjdVU1XL1QWwn8DycHSfcVoLdRB-z=H5jUeEPy4M91A@mail.gmail.com>
References: <84707.1549925963@critter.freebsd.dk>
 <CABoVN9DEjdVU1XL1QWwn8DycHSfcVoLdRB-z=H5jUeEPy4M91A@mail.gmail.com>
Message-ID: <66327.1549970560@critter.freebsd.dk>

--------
In message <CABoVN9DEjdVU1XL1QWwn8DycHSfcVoLdRB-z=H5jUeEPy4M91A at mail.gmail.com>, Dridi Boukelmoune writes:
>> But I am also seriously wondering if we should go even further and
>> have varnishd *only* produce JSON output, and leave the render-for-humans
>> aspect to varnishapi or even varnishadm.
>
>Ideally implement it in libvarnish.a and expose it in libvarnishapi,
>with a way for varnishadm to specify a window size in interactive
>mode. This way varnishd -d will be able to produce the plain text
>output.

I think you need to unpack that a bit before I follow ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dridi at varni.sh  Tue Feb 12 13:12:24 2019
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Tue, 12 Feb 2019 14:12:24 +0100
Subject: tabular CLI output proof of concept hack
In-Reply-To: <66327.1549970560@critter.freebsd.dk>
References: <84707.1549925963@critter.freebsd.dk>
 <CABoVN9DEjdVU1XL1QWwn8DycHSfcVoLdRB-z=H5jUeEPy4M91A@mail.gmail.com>
 <66327.1549970560@critter.freebsd.dk>
Message-ID: <CABoVN9BV9bFPW8NbZhP6NkUGcYzfeTCH5+MHGnvs0UOvcL6ffg@mail.gmail.com>

On Tue, Feb 12, 2019 at 12:22 PM Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> --------
> In message <CABoVN9DEjdVU1XL1QWwn8DycHSfcVoLdRB-z=H5jUeEPy4M91A at mail.gmail.com>, Dridi Boukelmoune writes:
> >> But I am also seriously wondering if we should go even further and
> >> have varnishd *only* produce JSON output, and leave the render-for-humans
> >> aspect to varnishapi or even varnishadm.
> >
> >Ideally implement it in libvarnish.a and expose it in libvarnishapi,
> >with a way for varnishadm to specify a window size in interactive
> >mode. This way varnishd -d will be able to produce the plain text
> >output.
>
> I think you need to unpack that a bit before I follow ?

My bad!

When you run varnishd -d from a terminal you may send CLI commands
from stdin and read responses from stdout. So whether it's in a VTC
log or run interactively, I think it would be harder to read the JSON
output (parsing with eyeballs=).

So my thought was that varnishd -d should stay human-friendly and
stick to plain text.

Dridi

From varnishmodules at gmail.com  Wed Feb 27 06:23:03 2019
From: varnishmodules at gmail.com (Varnish Modules)
Date: Wed, 27 Feb 2019 14:23:03 +0800
Subject: [Wanted] Varnish Module Freelance Developer
Message-ID: <CA+gdeemCaviJx3BkFGGVUW1QUT5fopEH9Sqxjv3er16WxfCO4g@mail.gmail.com>

Hi,

Our company is looking for a project-based freelancer to develop a Varnish
Module.

The current Varnish Module is only supporting up to version 4.

Our project requirement is to support the latest version of Varnish Cache.

If you are interested, please email me to request for further information.

- Kim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20190227/73d2acb5/attachment.html>