Mailing List Archive

Hi guys,

threw together some dates that we could focus on. My guess is that it
will be revised, but we might as well start somewhere.

April 20. Progressmeeting, Denmark.
June 1. Progressmeeting, Oslo.
June 26-30. Livetest.
July 10-28. Vacation?
August 7-11. Livetest 2.
August 14-17. Acceptancetest.
August 18. Deliverydate.

attached is also a iCal-file. I think Trac has support for that.

Also, could I get some feedback on:

http://klikk.vg.no/vcl.html

its good to know I am not throwing away time before I continue and
invent variables myself :)
Do we need a page like this or not?

I have also done some work on the "About" file that I might post
later tonight.
The "History" file is also near complete.

YS
Anders Berg

In message <D42EF9E4-357A-4135-B6D6-5ED9AB068540 at vgnett.no>, Anders Berg writes
:
>Hi guys,
>
>threw together some dates that we could focus on. My guess is that it
>will be revised, but we might as well start somewhere.
>
>April 20. Progressmeeting, Denmark.
>June 1. Progressmeeting, Oslo.
>June 26-30. Livetest.
>July 10-28. Vacation?
>August 7-11. Livetest 2.
>August 14-17. Acceptancetest.
>August 18. Deliverydate.

I've put them in my calendar and see no obvious conflicts, but as
usual, I need to confirm with the ?berkommando before I can
commit :-)

>http://klikk.vg.no/vcl.html
>
>its good to know I am not throwing away time before I continue and
>invent variables myself :)
>Do we need a page like this or not?

Yes, we will need a page like that.

I've decided to tackle the "varnish programming language" compiler
first because it gives us so much flexibility during development and
test that not doing it first doesn't make sense.

If you have time to write a couple of config files it would be great
to have some "actual" test data :-)

--
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.

In message <D42EF9E4-357A-4135-B6D6-5ED9AB068540 at vgnett.no>, Anders Berg writes
:
>Hi guys,
>
>threw together some dates that we could focus on. My guess is that it
>will be revised, but we might as well start somewhere.
>
>April 20. Progressmeeting, Denmark.
>June 1. Progressmeeting, Oslo.
>June 26-30. Livetest.
>July 10-28. Vacation?
>August 7-11. Livetest 2.
>August 14-17. Acceptancetest.
>August 18. Deliverydate.

I've put them in my calendar and see no obvious conflicts, but as
usual, I need to confirm with the ?berkommando before I can
commit :-)

>http://klikk.vg.no/vcl.html
>
>its good to know I am not throwing away time before I continue and
>invent variables myself :)
>Do we need a page like this or not?

Yes, we will need a page like that.

I've decided to tackle the "varnish programming language" compiler
first because it gives us so much flexibility during development and
test that not doing it first doesn't make sense.

If you have time to write a couple of config files it would be great
to have some "actual" test data :-)

--
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.

Anders Berg <andersb at vgnett.no> writes:
> threw together some dates that we could focus on. My guess is that
> it will be revised, but we might as well start somewhere.
>
> April 20. Progressmeeting, Denmark.
> June 1. Progressmeeting, Oslo.
> June 26-30. Livetest.
> July 10-28. Vacation?
> August 7-11. Livetest 2.
> August 14-17. Acceptancetest.
> August 18. Deliverydate.
>
> attached is also a iCal-file. I think Trac has support for that.

It can only export milestones in iCal format, not import - and
besides, mailman strips all attachments that have a mime-type that
doesn't start with "text/". I'll punch them in.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

Anders Berg <andersb at vgnett.no> writes:
> threw together some dates that we could focus on. My guess is that
> it will be revised, but we might as well start somewhere.
>
> April 20. Progressmeeting, Denmark.
> June 1. Progressmeeting, Oslo.
> June 26-30. Livetest.
> July 10-28. Vacation?
> August 7-11. Livetest 2.
> August 14-17. Acceptancetest.
> August 18. Deliverydate.
>
> attached is also a iCal-file. I think Trac has support for that.

It can only export milestones in iCal format, not import - and
besides, mailman strips all attachments that have a mime-type that
doesn't start with "text/". I'll punch them in.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

> In message <D42EF9E4-357A-4135-B6D6-5ED9AB068540 at vgnett.no>, Anders Berg
> writes
> :
>>Hi guys,
>>
>>threw together some dates that we could focus on. My guess is that it
>>will be revised, but we might as well start somewhere.
>>
>>April 20. Progressmeeting, Denmark.
>>June 1. Progressmeeting, Oslo.
>>June 26-30. Livetest.
>>July 10-28. Vacation?
>>August 7-11. Livetest 2.
>>August 14-17. Acceptancetest.
>>August 18. Deliverydate.
>
> I've put them in my calendar and see no obvious conflicts, but as
> usual, I need to confirm with the ?berkommando before I can
> commit :-)

Great :) Need to do the same. First of the vacation bit can be "tricky".
Secondly, the deliver date is so close to my weedingdate (when I get to be
a small department in the ?berkommando, 26. August) that it may cause some
problems there.

>>http://klikk.vg.no/vcl.html
>>
>>its good to know I am not throwing away time before I continue and
>>invent variables myself :)
>>Do we need a page like this or not?
>
> Yes, we will need a page like that.
>
> I've decided to tackle the "varnish programming language" compiler
> first because it gives us so much flexibility during development and
> test that not doing it first doesn't make sense.

I agree. Done some more work on: http://klikk.vg.no/vcl.html

But I am having trouble to structure the document right.

> If you have time to write a couple of config files it would be great
> to have some "actual" test data :-)

Yes, when the "varnish programming language" is more defined I will write
some mockups.

Anders Berg

> --
> 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.
>
>

> In message <D42EF9E4-357A-4135-B6D6-5ED9AB068540 at vgnett.no>, Anders Berg
> writes
> :
>>Hi guys,
>>
>>threw together some dates that we could focus on. My guess is that it
>>will be revised, but we might as well start somewhere.
>>
>>April 20. Progressmeeting, Denmark.
>>June 1. Progressmeeting, Oslo.
>>June 26-30. Livetest.
>>July 10-28. Vacation?
>>August 7-11. Livetest 2.
>>August 14-17. Acceptancetest.
>>August 18. Deliverydate.
>
> I've put them in my calendar and see no obvious conflicts, but as
> usual, I need to confirm with the ?berkommando before I can
> commit :-)

Great :) Need to do the same. First of the vacation bit can be "tricky".
Secondly, the deliver date is so close to my weedingdate (when I get to be
a small department in the ?berkommando, 26. August) that it may cause some
problems there.

>>http://klikk.vg.no/vcl.html
>>
>>its good to know I am not throwing away time before I continue and
>>invent variables myself :)
>>Do we need a page like this or not?
>
> Yes, we will need a page like that.
>
> I've decided to tackle the "varnish programming language" compiler
> first because it gives us so much flexibility during development and
> test that not doing it first doesn't make sense.

I agree. Done some more work on: http://klikk.vg.no/vcl.html

But I am having trouble to structure the document right.

> If you have time to write a couple of config files it would be great
> to have some "actual" test data :-)

Yes, when the "varnish programming language" is more defined I will write
some mockups.

Anders Berg

> --
> 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.
>
>

In message <1947.193.213.34.102.1141692949.squirrel at denise.vg.no>, "Anders Berg
" writes:

>>>http://klikk.vg.no/vcl.html

>> I've decided to tackle the "varnish programming language" compiler

Varnish Configuration Language makes more sense, it is less frightening
that a "programming language".

>But I am having trouble to structure the document right.

I actually like it, we will need a reference document like that at the
end.

Here are some comments:

no-cache -> no_cache
no-new-cache -> no_new_cache
I realized that it is easier if I don't have to check
for double meaning of '-' so lets use underscore instead.

req.ttlfactor
I actually wanted to have one per request also, so that
it is possible to decide that somebody isn't very important.
(microsoft proxy thing)

req.backend
Not sure what I was thinking.

--
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.

In message <1947.193.213.34.102.1141692949.squirrel at denise.vg.no>, "Anders Berg
" writes:

>>>http://klikk.vg.no/vcl.html

>> I've decided to tackle the "varnish programming language" compiler

Varnish Configuration Language makes more sense, it is less frightening
that a "programming language".

>But I am having trouble to structure the document right.

I actually like it, we will need a reference document like that at the
end.

Here are some comments:

no-cache -> no_cache
no-new-cache -> no_new_cache
I realized that it is easier if I don't have to check
for double meaning of '-' so lets use underscore instead.

req.ttlfactor
I actually wanted to have one per request also, so that
it is possible to decide that somebody isn't very important.
(microsoft proxy thing)

req.backend
Not sure what I was thinking.

--
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.

> In message <1947.193.213.34.102.1141692949.squirrel at denise.vg.no>, "Anders
> Berg
> " writes:
>
>>>>http://klikk.vg.no/vcl.html
>
>>> I've decided to tackle the "varnish programming language" compiler
>
> Varnish Configuration Language makes more sense, it is less frightening
> that a "programming language".

Yes. I would guess so.

>>But I am having trouble to structure the document right.
>
> I actually like it, we will need a reference document like that at the
> end.
>
> Here are some comments:
>
> no-cache -> no_cache
> no-new-cache -> no_new_cache
> I realized that it is easier if I don't have to check
> for double meaning of '-' so lets use underscore instead.
>
> req.ttlfactor
> I actually wanted to have one per request also, so that
> it is possible to decide that somebody isn't very important.
> (microsoft proxy thing)
>
> req.backend
> Not sure what I was thinking.

Fixed. One thing that eluded me so far is how we are gonna configure the
storage backend(s).

Are we looking at something like:

storage.type = disk|memory
storage.size = 200M
storage.depth = 16 256
storage.algorithm = LRU

But that means they must be configurable in runtime. What happens when one
changes: storage.type = disk -> storage.type = memory ?

Or is this gonna be implemented from the commandline tool and part of the
managment protocol?

Anyone have any thoughts?

Ab

> --
> 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.
>
>

> In message <1947.193.213.34.102.1141692949.squirrel at denise.vg.no>, "Anders
> Berg
> " writes:
>
>>>>http://klikk.vg.no/vcl.html
>
>>> I've decided to tackle the "varnish programming language" compiler
>
> Varnish Configuration Language makes more sense, it is less frightening
> that a "programming language".

Yes. I would guess so.

>>But I am having trouble to structure the document right.
>
> I actually like it, we will need a reference document like that at the
> end.
>
> Here are some comments:
>
> no-cache -> no_cache
> no-new-cache -> no_new_cache
> I realized that it is easier if I don't have to check
> for double meaning of '-' so lets use underscore instead.
>
> req.ttlfactor
> I actually wanted to have one per request also, so that
> it is possible to decide that somebody isn't very important.
> (microsoft proxy thing)
>
> req.backend
> Not sure what I was thinking.

Fixed. One thing that eluded me so far is how we are gonna configure the
storage backend(s).

Are we looking at something like:

storage.type = disk|memory
storage.size = 200M
storage.depth = 16 256
storage.algorithm = LRU

But that means they must be configurable in runtime. What happens when one
changes: storage.type = disk -> storage.type = memory ?

Or is this gonna be implemented from the commandline tool and part of the
managment protocol?

Anyone have any thoughts?

Ab

> --
> 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.
>
>

In message <1231.193.213.34.102.1141725469.squirrel at denise.vg.no>, "Anders Berg
" writes:


>Fixed. One thing that eluded me so far is how we are gonna configure the
>storage backend(s).
>
>Or is this gonna be implemented from the commandline tool and part of the
>managment protocol?
>

Yes.

Storage will be defined with command line args or if that gets too
unweildy, with a traditional config file for the management process.

--
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.

In message <1231.193.213.34.102.1141725469.squirrel at denise.vg.no>, "Anders Berg
" writes:


>Fixed. One thing that eluded me so far is how we are gonna configure the
>storage backend(s).
>
>Or is this gonna be implemented from the commandline tool and part of the
>managment protocol?
>

Yes.

Storage will be defined with command line args or if that gets too
unweildy, with a traditional config file for the management process.

--
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.

> In message <1947.193.213.34.102.1141692949.squirrel at denise.vg.no>, "Anders
> Berg
> " writes:
>
>
> Here are some comments:
>
> req.ttlfactor
> I actually wanted to have one per request also, so that
> it is possible to decide that somebody isn't very important.
> (microsoft proxy thing)
>

What do you mean with that?

if (req.header.User-Agent ~ "MS Proxy"){
req.ttlfactor = 1.5
}

Like this?
Would not:

if (req.header.User-Agent ~ "MS Proxy"){
obj.ttl += 10m
}


be the same?

As you can see I have noticed I really do not understand obj.ttl like
mentioned in notes1 (as I thought I did).

obj.ttl can either act like a modifier on the Expire output, on the object
itself, and as "deliver stale for ttl more seconds". Which one is it?

Lets say an object (index.html) expires:

Expires: Tue, 14 Mar 2006 16:00:00 GMT

from the backend.

The object is matched in the config.

if (req.url.path ~ "index.html"){
obj.ttl += 10m
}

would the object stored in memory, or storage backend, be modified such
that Varnish reads:

Expires: Tue, 14 Mar 2006 16:10:00 GMT

next time? In that case well, that request would make it (if it is not
flagged as matching that exact reg-exp, which could be the case):

Expires: Tue, 14 Mar 2006 16:20:00 GMT

The document would never expire if we modify the object in memory or disk
(and don't flag it). So lets look at the other approach, where the object
is just modified on the "output" side.

The object gets:

Expires: Tue, 14 Mar 2006 16:00:00 GMT

from the backend. Is stored in memory, is requested, and delivers:

Expires: Tue, 14 Mar 2006 16:10:00 GMT

back to the requester.

@ Tue, 14 Mar 2006 16:00:01 GMT

we have to get a new document from the backend (we do not lighten load),
and lets say we delivered 3000 requests with:

Expires: Tue, 14 Mar 2006 16:10:00 GMT

well, 3000 clients are gonna request that document then (if they ask for
it again, which is the point, or else, obj.ttl has no meaning). What we
just did was to "buy" ourselvs 10 min at the first hit/request, nothing
more, because its a sliding window and does not lessen load on backend.

So I guess obj.ttl would be used to say that even if the document is
expired, let it live 10 more minutes in cache. Used like this:

Backend delivers a:

Expires: Tue, 14 Mar 2006 16:00:00 GMT

document to Varnish.

Request comes @ Tue, 14 Mar 2006 16:00:01 GMT and hits.

if (req.header.User-Agent ~ "MS Proxy"){
obj.ttl += 10m
}

then old document is delivered.

This is the only way I can see this variable beeing used, and then it will
be the same as req.ttlfactor in my opinion. It does not really make sense
to use it on all requests, because then it would be the same as saying "I
don't wanna control my Expires from my backend", which one really should.
Or is this variable for controlling exactly that? "It's easier to do on
Varnish since I have 5 backends, so lets do it there".

Sorry for using so much text to say/ask so little. But I see it as one of
those "problems" that have to be discussed in detail.


Ab

> --
> 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.
>
>

> In message <1947.193.213.34.102.1141692949.squirrel at denise.vg.no>, "Anders
> Berg
> " writes:
>
>
> Here are some comments:
>
> req.ttlfactor
> I actually wanted to have one per request also, so that
> it is possible to decide that somebody isn't very important.
> (microsoft proxy thing)
>

What do you mean with that?

if (req.header.User-Agent ~ "MS Proxy"){
req.ttlfactor = 1.5
}

Like this?
Would not:

if (req.header.User-Agent ~ "MS Proxy"){
obj.ttl += 10m
}


be the same?

As you can see I have noticed I really do not understand obj.ttl like
mentioned in notes1 (as I thought I did).

obj.ttl can either act like a modifier on the Expire output, on the object
itself, and as "deliver stale for ttl more seconds". Which one is it?

Lets say an object (index.html) expires:

Expires: Tue, 14 Mar 2006 16:00:00 GMT

from the backend.

The object is matched in the config.

if (req.url.path ~ "index.html"){
obj.ttl += 10m
}

would the object stored in memory, or storage backend, be modified such
that Varnish reads:

Expires: Tue, 14 Mar 2006 16:10:00 GMT

next time? In that case well, that request would make it (if it is not
flagged as matching that exact reg-exp, which could be the case):

Expires: Tue, 14 Mar 2006 16:20:00 GMT

The document would never expire if we modify the object in memory or disk
(and don't flag it). So lets look at the other approach, where the object
is just modified on the "output" side.

The object gets:

Expires: Tue, 14 Mar 2006 16:00:00 GMT

from the backend. Is stored in memory, is requested, and delivers:

Expires: Tue, 14 Mar 2006 16:10:00 GMT

back to the requester.

@ Tue, 14 Mar 2006 16:00:01 GMT

we have to get a new document from the backend (we do not lighten load),
and lets say we delivered 3000 requests with:

Expires: Tue, 14 Mar 2006 16:10:00 GMT

well, 3000 clients are gonna request that document then (if they ask for
it again, which is the point, or else, obj.ttl has no meaning). What we
just did was to "buy" ourselvs 10 min at the first hit/request, nothing
more, because its a sliding window and does not lessen load on backend.

So I guess obj.ttl would be used to say that even if the document is
expired, let it live 10 more minutes in cache. Used like this:

Backend delivers a:

Expires: Tue, 14 Mar 2006 16:00:00 GMT

document to Varnish.

Request comes @ Tue, 14 Mar 2006 16:00:01 GMT and hits.

if (req.header.User-Agent ~ "MS Proxy"){
obj.ttl += 10m
}

then old document is delivered.

This is the only way I can see this variable beeing used, and then it will
be the same as req.ttlfactor in my opinion. It does not really make sense
to use it on all requests, because then it would be the same as saying "I
don't wanna control my Expires from my backend", which one really should.
Or is this variable for controlling exactly that? "It's easier to do on
Varnish since I have 5 backends, so lets do it there".

Sorry for using so much text to say/ask so little. But I see it as one of
those "problems" that have to be discussed in detail.


Ab

> --
> 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.
>
>

In message <2168.193.213.34.102.1142289116.squirrel at denise.vg.no>, "Anders Berg
" writes:

>> Here are some comments:
>>
>> req.ttlfactor
>> I actually wanted to have one per request also, so that
>> it is possible to decide that somebody isn't very important.
>> (microsoft proxy thing)
>>
>
>What do you mean with that?

I guess you have thought more about it than I have now, and it doesn't
seem to work after all :-)

This is the sort of thing I hope we will discover more off as we start
writing some actual VCL encoded policies.

--
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.

In message <2168.193.213.34.102.1142289116.squirrel at denise.vg.no>, "Anders Berg
" writes:

>> Here are some comments:
>>
>> req.ttlfactor
>> I actually wanted to have one per request also, so that
>> it is possible to decide that somebody isn't very important.
>> (microsoft proxy thing)
>>
>
>What do you mean with that?

I guess you have thought more about it than I have now, and it doesn't
seem to work after all :-)

This is the sort of thing I hope we will discover more off as we start
writing some actual VCL encoded policies.

--
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.