From phk at phk.freebsd.dk  Mon Apr  3 08:04:39 2006
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 03 Apr 2006 10:04:39 +0200
Subject: pass-through mode
Message-ID: <82822.1144051479@critter.freebsd.dk>


My intention was to get pass-through mode working first, since that
will allow me to run varnishd and have things "work" etc.

But now that I think about pass-through mode I realized that it is
not quite as trivial as I thought.

The truly trivial way to do it is to simply act as a pipe:  Anything
coming from the client we relay to the backend and vice versa.  This
is trivial to implement because no http header parsing or anything
like it is necessary: a simple byte tunnel.

The side effect of this scheme is that if the client does something
which causes a pass-through transaction, then everything else on
that TCP session will bypass the cache and go directly to the
backend.  This means amongst other things that rewrites will not
happen on these requests.

Always injecting a "Connection: close" to the backend, so that only
a single transaction will happen is not a solid solution.  Not only
does it cost us more TCP connections,  but this might also break
some applications which expect to keep the TCP connection open
(authentication private java protocols etc).

The other way is to assume that it is HTTP traffic, do the http
header parsing in both directions and take it from there.  (This
is only slightly more code, because a lot of it is reuse.) But, for
that to work it requires that nothing strange is going on and that
the protocol remains HTTP.

So I think my conclusion is that we may need both a "pipe-through"
and a "pass-through" mode, with pass-through being the default
for non GET+HEAD transactions.

-- 
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 phk at phk.freebsd.dk  Mon Apr  3 08:44:25 2006
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 03 Apr 2006 10:44:25 +0200
Subject: can we take libevent from their CVS repo ?
Message-ID: <90526.1144053865@critter.freebsd.dk>


Is it possible to take the head version of libevent from the
their CVS repo ?  The version we have does not allow one to
delete an eventengine again, and rather than add a workaround
with a pool of eventengines, I'd rather we pull in the head
version which has the delete function...

-- 
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 des at linpro.no  Mon Apr  3 10:35:07 2006
From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=)
Date: Mon, 03 Apr 2006 12:35:07 +0200
Subject: can we take libevent from their CVS repo ?
References: <90526.1144053865@critter.freebsd.dk>
Message-ID: <ujrslovj6as.fsf@cat.linpro.no>

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> Is it possible to take the head version of libevent from the their
> CVS repo?

Of course...  Do you want me to take care of it?

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


From des at linpro.no  Mon Apr  3 11:07:48 2006
From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=)
Date: Mon, 03 Apr 2006 13:07:48 +0200
Subject: r96 - trunk/varnish-cache/bin/varnishd
References: <20060403110328.7D42E1ED604@projects.linpro.no>
Message-ID: <ujrodzikjcr.fsf@cat.linpro.no>

phk at projects.linpro.no writes:
> Log:
> How I wish people would think more ahead when writing libraries like
> libevent.  The entire "implicit event engine" api assumption stinks.

Can you explain what's wrong with it?

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


From phk at phk.freebsd.dk  Mon Apr  3 11:30:07 2006
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 03 Apr 2006 13:30:07 +0200
Subject: r96 - trunk/varnish-cache/bin/varnishd 
In-Reply-To: Your message of "Mon, 03 Apr 2006 13:07:48 +0200."
	<ujrodzikjcr.fsf@cat.linpro.no> 
Message-ID: <12102.1144063807@critter.freebsd.dk>

In message <ujrodzikjcr.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgra
v?= writes:
>phk at projects.linpro.no writes:
>> Log:
>> How I wish people would think more ahead when writing libraries like
>> libevent.  The entire "implicit event engine" api assumption stinks.
>
>Can you explain what's wrong with it?

Here is the email I just sent to Niels Provos:

>============================================================================
>From:    Poul-Henning Kamp <phk at phk.freebsd.dk>
>Subject: libevent, some comments.
>To:      provos at citi.umich.edu
>Message-Id: <12019.1144063692 at critter.freebsd.dk>
>Date:    Mon, 03 Apr 2006 13:28:12 +0200
>
>
>Please don't take this the wrong way, it is meant to be a constructive
>critisism of libevent.
>
>The background is that I'm writing an application (OSS) which needs
>several event engines in multiple threads and a lot of other
>quasinasty stuff.
>
>My choice was between ISC/s eventlib and your libevent and my initial
>choice where to go with your libevent because of the kqueue support.
>
>Against your libevent counts that the API is quite a mess by now,
>and a far cry from the very stringent and quite fool-proof API
>of the ISC library.
>
>Having gotten somewhat down the road now, I feel that I'm in a position
>to point out a number of improvements to libevent which could make
>it a better proposition for "the default event library".
>
>I hope you'll consider my input.
>
>Poul-Henning
>
>PS: If you're going to be at BSDcan in Ottawa, we can find some time
>and hash the details out if you like.
>
>1: Multi engine support is a mess.
>----------------------------------
>
>The fact that multiple eventengines in the same namespace is bolted
>on later has two unfortunate effects:  It messes up the namespace
>with foo_base_bar() functions and it leaves a giant hole for messing
>things up if people are not very very alert.
>
>I would recommend (and be willing to do a lot of the work) that
>a v2 of libevent is created by taking the current sources, making
>the eventbase mandatory throughout and start a new and more systematic
>namespace ("evb_foo()" or "evl_foo()" ?)
>
>A trivial layer of wrapper macros can then implement the current
>ABI, on top of the new one so that nobody will have to rewrite their
>apps unless they want to.
>
>
>2: Timestamp handling
>---------------------
>
>I would recommend is that you adobt some of the time-handling
>facilities from named/ISC's eventlibrary.
>
>Passing a struct timespec instead of a pointer to it may offend old
>C-coders like us, but it makes for much cleaner source code for the
>users:
>
>	struct timespec foo;
>
>	foo.tv_sec = 1;
>	foo.tv_nsec = 0;
>	evtimer_mumble(ev, &foo)
>
>vs
>
>	evtimer_mumble(ev, TimeSpec(1, 0))
>
>The TimeSpec function looks like this:
>
>	struct timespec
>	TimeSpec(time_t sec, long nsec)
>	{
>		struct timespec ts;
>
>		ts.tv_sec = sec;
>		ts.tv_nsec = nsec;
>		return (ts);
>	}
>
>And yes, that is legal in all but the most antique compilers.
>
>The advantage of this is that it eliminates the memory management
>for the timestamps out of the users responsibility.
>
>The big advantage comes once you have to start doing math on
>your timestamps:
>
>	evtime_mumble(ev, TimeAdd(default_timeout, TimeSpec(10, 0)));
>
>
>
>3: Use CLOCK_MONOTONIC
>----------------------
>
>An eventlibrary should use CLOCK_MONOTONIC to avoid being affected
>by clock-steps from NTPD or similar.
>
>If UTC timing is required, an per event-engine option could switch
>to CLOCK_REALTIME.
>
>
>4: Be carefull with layered facilities
>--------------------------------------
>
>As convenient as http support is, not everybody will need it,
>and for others usurping the http_* and HTTP_* namespace will
>be a major problem in using libevent.
>
>I would propose that the http support be put in a separate
>library or at the very least hidden under a
>
>	#ifndef I_DO_NOTWANT_LIBEVENT_HTTP_SUPPORT
>
>so that the namespace polution can be avoided.
>
>-- 
>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.

-- 
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 phk at phk.freebsd.dk  Mon Apr  3 11:30:29 2006
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 03 Apr 2006 13:30:29 +0200
Subject: can we take libevent from their CVS repo ? 
In-Reply-To: Your message of "Mon, 03 Apr 2006 12:35:07 +0200."
	<ujrslovj6as.fsf@cat.linpro.no> 
Message-ID: <12114.1144063829@critter.freebsd.dk>

In message <ujrslovj6as.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgra
v?= writes:
>"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
>> Is it possible to take the head version of libevent from the their
>> CVS repo?
>
>Of course...  Do you want me to take care of it?

That would be great!

-- 
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 des at linpro.no  Mon Apr  3 12:08:41 2006
From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=)
Date: Mon, 03 Apr 2006 14:08:41 +0200
Subject: r96 - trunk/varnish-cache/bin/varnishd
References: <12102.1144063807@critter.freebsd.dk>
Message-ID: <ujrhd5akgja.fsf@cat.linpro.no>

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> As convenient as http support is, not everybody will need it,
> and for others usurping the http_* and HTTP_* namespace will
> be a major problem in using libevent.
>
> I would propose that the http support be put in a separate
> library or at the very least hidden under a
>
>	#ifndef I_DO_NOTWANT_LIBEVENT_HTTP_SUPPORT
>
> so that the namespace polution can be avoided.

The middle road would be to move macros and prototypes for the HTTP
functionality to a separate header.  This shouldn't break any existing
software, since the HTTP code is not present in any released version
of libevent.

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


From des at linpro.no  Mon Apr  3 14:26:29 2006
From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=)
Date: Mon, 03 Apr 2006 16:26:29 +0200
Subject: Linux patches
Message-ID: <ujrr74eivl6.fsf@cat.linpro.no>

The attached patch goes a long way towards fixing the build on Linux.
There are still issues (glibc doesn't have strl*), but I don't have
time to address them right now.

The two major changes are the removal of __DECONST (I've changed
ParseArgv() and FreeArgv() to operate on const char ** instead, and
FreeArgv() does an explicit dequalification) and the removal of
digittoint() (which is pointless, as ISO C guarantees that digits are
consecutive in the execution character set, so ch - '0' works just as
well).

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: varnish.diff
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20060403/2910060c/attachment.ksh>

From des at linpro.no  Mon Apr  3 14:28:54 2006
From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=)
Date: Mon, 03 Apr 2006 16:28:54 +0200
Subject: Linux patches
References: <ujrr74eivl6.fsf@cat.linpro.no>
Message-ID: <ujrmzf2ivh5.fsf@cat.linpro.no>

des at linpro.no (Dag-Erling Sm?rgrav) writes:
> The attached patch goes a long way towards fixing the build on Linux.
> There are still issues (glibc doesn't have strl*), but I don't have
> time to address them right now.

Note that there are also portability issues in some of the Makefiles,
but I won't spend any time on them at this point; they shouldn't be a
problem unless we try to build with a non-GNU toolchain.

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


From phk at phk.freebsd.dk  Mon Apr  3 14:33:03 2006
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 03 Apr 2006 16:33:03 +0200
Subject: Linux patches 
In-Reply-To: Your message of "Mon, 03 Apr 2006 16:26:29 +0200."
	<ujrr74eivl6.fsf@cat.linpro.no> 
Message-ID: <78901.1144074783@critter.freebsd.dk>

In message <ujrr74eivl6.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= writes:
>--=-=-=
>Content-Type: text/plain; charset=iso-8859-1
>Content-Transfer-Encoding: 8bit
>
>The attached patch goes a long way towards fixing the build on Linux.
>There are still issues (glibc doesn't have strl*), but I don't have
>time to address them right now.

By all means just commit this stuff.

Right now I'm focusing on "getting a hole through", then once we get
there I expect a major "now that we know how it will work" cleanup
that would also aim for better portability.

-- 
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 des at linpro.no  Mon Apr  3 14:30:57 2006
From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=)
Date: Mon, 03 Apr 2006 16:30:57 +0200
Subject: Id tags
Message-ID: <ujrirpqivdq.fsf@cat.linpro.no>

Subversion does not automatically expand $Id$ tags; you need to
explicitly set the svn:keywords property on each file.  For instance:

$ svn propset svn:keywords Id foo.c
$ svn commit -m'Expand Id' foo.c

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


From phk at phk.freebsd.dk  Mon Apr  3 14:40:50 2006
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 03 Apr 2006 16:40:50 +0200
Subject: Id tags 
In-Reply-To: Your message of "Mon, 03 Apr 2006 16:30:57 +0200."
	<ujrirpqivdq.fsf@cat.linpro.no> 
Message-ID: <79028.1144075250@critter.freebsd.dk>

In message <ujrirpqivdq.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= writes:

>Subversion does not automatically expand $Id$ tags; you need to
>explicitly set the svn:keywords property on each file.  For instance:
>
>$ svn propset svn:keywords Id foo.c
>$ svn commit -m'Expand Id' foo.c

I noticed that.  I'll catch them next time I see them.

-- 
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 des at linpro.no  Tue Apr  4 10:10:56 2006
From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=)
Date: Tue, 04 Apr 2006 12:10:56 +0200
Subject: Linux patches
References: <78901.1144074783@critter.freebsd.dk>
Message-ID: <ujr1wwdirbj.fsf@cat.linpro.no>

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> Right now I'm focusing on "getting a hole through", then once we get
> there I expect a major "now that we know how it will work" cleanup
> that would also aim for better portability.

That's fine, but there's one thing I'm not too happy about: you
reimplemented the logging code in a non-portable manner instead of
using the existing, portable implementation I had written.

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


From phk at phk.freebsd.dk  Tue Apr  4 10:43:15 2006
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 04 Apr 2006 12:43:15 +0200
Subject: Linux patches 
In-Reply-To: Your message of "Tue, 04 Apr 2006 12:10:56 +0200."
	<ujr1wwdirbj.fsf@cat.linpro.no> 
Message-ID: <62579.1144147395@critter.freebsd.dk>

In message <ujr1wwdirbj.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgra
v?= writes:
>"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
>> Right now I'm focusing on "getting a hole through", then once we get
>> there I expect a major "now that we know how it will work" cleanup
>> that would also aim for better portability.
>
>That's fine, but there's one thing I'm not too happy about: you
>reimplemented the logging code in a non-portable manner instead of
>using the existing, portable implementation I had written.

It's not lack of appreciation as much as rund hole and square peg
that made be jump the fence on that one for now.

Please for now consider this a prototype for validating our design,
and do not get too disturbed by stylistic stuff.  There are a lot
of decisions that I need to take based on experiments (for instance:
is it too expensive to recognize all HTTP headers up front compared
to identifying them only as/if we need them ?)

Once these things settle out, pretty much all the code will need
a serious polishing and portabilization.


-- 
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 phk at phk.freebsd.dk  Thu Apr  6 10:42:33 2006
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 06 Apr 2006 12:42:33 +0200
Subject: passthrough works
Message-ID: <18436.1144320153@critter.freebsd.dk>


I think we can declare the "hole through" milestone reached now.
I can see both www.cnn.com and www.freebsd.org in my firefox.

The HTTP header processing is very minimal and it won't take much
for a client or server to confuse varnishd at this point, but in a
controlled setting things survive.  (I've stopped leaking backend
connections but probably not memory yet).

To me this is an important milestone because it allows us to work
on multiple aspects of varnishd in parallel now, without getting
in the way of each other.

The VCL language definition and implementation can now progress at
least as far as header inspection and modification (including
URL rewriting).

At the same time, the actual cache implementation can proceed in
the background.


But I'm starting to reconsider the "unified" VCL idea again.

With the "unified" VCL execution where the object lookup and fetch
are explicit VCL actions, we need to park a worker thread on each
request because in essence that means VCL can sleep.

This implies that splitting the worker threads into "senders" and
"receivers" is of no benefit and instead we will just have one
(finite) pool of worker threads.

That again implies that in order to limit how hard we will hit
the backend we need to make backend-connections a pooled resource
which worker-threads may have to wait for.

Which again means that we could have a "pile-up" where all the
worker threads are waiting for backend connections and none of
them service the cached requests.  Adding more workerthreads
will not solve this issue if the backed is very slow or similar.

Overall, this is not a situation I'm happy about, parking a thread
for each request waiting for a resource is pretty much exactly
what I do not want to do.

One real solution is to checkpoint the VCL execution so that we
don't have on-stack context while doing things which might sleep,
but this is somewhat complex in the compiler because a full path
analysis and tree-pruning needs to be performed and the result of
that can be quite explosive in size, if for instance "fetch" is
called conditionally in a subroutine.

Another real solution is to make VCL execution restartable, that
is less complicated, but still in the ugly-bugly category.

And finally there is the option of making the sleeping actions
terminal in the VCL language, so that "fetch" means that the
VCL function excution stops at that point.

That forces us to give up the "a single main function",
model and instead use several VCL functions:

Legend:
	[VCL-function]
	<sleeping action>

                [pre-lookup]
                     |
                     |
                     |
                 <lookup>
                   /  \
                  /    \
                 /      \
              [hit]    [miss] 
                /\      / 
               /  \    / 
              /    \  /
             |    <fetch>
             |       |
             |       |
             |       |
             |   [post-fetch]
             |    /
             |   /
             |  /
           <finish>

I'm particularly worried about introducing complexity in VCL so
your input on this, (does this diagram even make sense to you ?)
would be most appreciated.

Poul-Henning

-- 
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 phk at phk.freebsd.dk  Thu Apr  6 11:16:25 2006
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 06 Apr 2006 13:16:25 +0200
Subject: meeting 20th april ?
Message-ID: <18607.1144322185@critter.freebsd.dk>


Did we finalize the progress meeting on april 20th or is that
still up in the air ?

Did you guys want to come .dk or will i be going to .no ?

-- 
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 des at linpro.no  Thu Apr  6 11:24:36 2006
From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=)
Date: Thu, 06 Apr 2006 13:24:36 +0200
Subject: meeting 20th april ?
References: <18607.1144322185@critter.freebsd.dk>
Message-ID: <ujrirpn2bgr.fsf@cat.linpro.no>

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> Did we finalize the progress meeting on april 20th or is that still
> up in the air ?

I think it's still up in the air, but it was supposed to be in Denmark
according to Anders's schedule.

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


From phk at phk.freebsd.dk  Mon Apr 10 20:36:18 2006
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 10 Apr 2006 22:36:18 +0200
Subject: hash algorithms...
Message-ID: <43309.1144701378@critter.freebsd.dk>


Anders: the is mostly n?rd talk, don't despair :-)

Between the phone and my email, I have been playing with hash
algorithms today.

I looked at the google code, and it's very neat, but it's C++
templates and I don't feel like having two languages involved.

Also, the google code is very focused on memory usage, but we're
going to store objects of typically a few hundred bytes for each
index, so it is not critical that we spend only a few bits per
item on the hashing.

In fact, for us it is more important that inserts/deletes interfere
as little as possible with lookups.

One thing struck me, and that is that ideally we would need to hash
more than just the URL.  A given document could exist in different
languages or formats, selected by HTTP header, rather than by URL.
For now that is going to be an item in the "notes".  One way to
handle it later on is with a VCL function doing the lookup, and the
lookup command in VCL taking arguments of some kind.


I will pack the hash-table functionality in a well defined interface
(Insert, Delete, Lookup) so that we can have multiple implementations
later on.  Which one to use will then be a command-line parameter.

My guess is that the default hash table will be something like this:

	calculate a hash of the URL.  (exact algorithm TBD, I've used
	MD5 for my experiments).

	First byte of the hash indexes an array of 256 pointers.

	while (object not resolved) {
		Pointer either points to a sorted (by hash) linked
		list or another 256 pointer array (indexed by the next
		byte of the hash).
	}

	When a linked list grows more than X items, it is converted
	to a 256 pointer array.  Conversion from array to list
	is never done.

I played with having both 256 and 16 bucket arrays, the closer one
gets to the leaf the less dense the tree is and therefore a linked
list seems to be behave better in the range from the twigs to the
leaves.

Up to around a thousand URLs this gives one array indexing and up
to approx 8 list entries to check.

Up to around 100k URLs it gives two index operations and a few list
entries.

Up to over 10M URls it gives three index operations and a few
list entries.

Overall, memory usage is around 13-19 bytes per URL.

Locking, is like a filesystems directory tree:

	A global lock (actually inside the root 256-array) protects 
	all pointers in the root 256-array.

	When the first array has been indexed, the listhead or
	256-array will contain another lock which we grab before
	releaseing the toplevel lock.

	To change a list to an array, both the parent and the list
	lock must be held.

I think mutexes will be OK for this because the fan-out is quite
big.  Rw-locks could be used if there is too much contention, but
I'd prefer to avoid the lock-upgrade issue.

More later when I try to implement this.

-- 
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 andersb at vgnett.no  Mon Apr 10 21:46:26 2006
From: andersb at vgnett.no (Anders Berg)
Date: Mon, 10 Apr 2006 23:46:26 +0200 (CEST)
Subject: hash algorithms...
In-Reply-To: <43309.1144701378@critter.freebsd.dk>
References: <43309.1144701378@critter.freebsd.dk>
Message-ID: <2732.193.213.34.102.1144705586.squirrel@denise.vg.no>

>
> Anders: the is mostly n?rd talk, don't despair :-)

I'm cool :)

> One thing struck me, and that is that ideally we would need to hash
> more than just the URL.  A given document could exist in different
> languages or formats, selected by HTTP header, rather than by URL.
> For now that is going to be an item in the "notes".  One way to
> handle it later on is with a VCL function doing the lookup, and the
> lookup command in VCL taking arguments of some kind.

Yes, you are right. To implement support for gzip'ed files we need more
than the URL, probably URL, Content-Encoding and User-Agent.
Potentially that means many different versions of each file, and will
probably be a hassle to work with in VCL. The reason I threw in User-Agent
are clients that don't behave according to RFC 2616. I am told that they
exist. This really makes it hard to implement support for gzip'ed files
without a performance dent, and it could also render Varnish less useful,
with many browsers having exotic names:

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; ABS)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SP/6.36/1.01/HP; .NET
CLR 1.1.4322)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; FunWebProducts;
.NET CLR 1.1.4322)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Crazy Browser 2.0.1)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Dialer/1.10/ADSL;
.NET CLR 1.1.4322)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322;
.NET CLR 1.0.3705; InfoPath.1)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; SIMBAR Enabled;
.NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727)


(I am not making this up. This is a _extract_ from a logg file over 5 min.)

So to find a good solution to this problem we need to digg deep (do all
the MSIE 6.0 behave alike? etc.).

But I guess thats for later. Be sure to tell me if you need logs. I have
loads of them.

Just my thoughts about "hashing" :)

Anders Berg


From des at linpro.no  Tue Apr 11 07:40:52 2006
From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=)
Date: Tue, 11 Apr 2006 09:40:52 +0200
Subject: hash algorithms...
References: <43309.1144701378@critter.freebsd.dk>
Message-ID: <ujrpsjov9tn.fsf@cat.linpro.no>

Poul-Henning Kamp <phk at phk.freebsd.dk> writes:
> Between the phone and my email, I have been playing with hash
> algorithms today.

I'd like to point out the difference between a hash function and a
hash table...  I agree that we need a hash function, but if we use
md5, it's probably simpler and faster to keep the data in a red-black
tree with the hash value as lookup key than in a hash table where we
need to further hash the md5 digest and are guaranteed to get
collisions.

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


From phk at phk.freebsd.dk  Tue Apr 11 08:14:30 2006
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 11 Apr 2006 10:14:30 +0200
Subject: hash algorithms... 
In-Reply-To: Your message of "Tue, 11 Apr 2006 09:40:52 +0200."
	<ujrpsjov9tn.fsf@cat.linpro.no> 
Message-ID: <54984.1144743270@critter.freebsd.dk>

In message <ujrpsjov9tn.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= wri
tes:
>Poul-Henning Kamp <phk at phk.freebsd.dk> writes:
>> Between the phone and my email, I have been playing with hash
>> algorithms today.
>
>I'd like to point out the difference between a hash function and a
>hash table...

Sorry for sloppy terminology here.

>hash table...  I agree that we need a hash function, but if we use
>md5, it's probably simpler and faster to keep the data in a red-black
>tree with the hash value as lookup key than in a hash table where we
>need to further hash the md5 digest and are guaranteed to get
>collisions.

The number of URLs you're managing will have a lot to do with which
algorithm is best.  If you have a million URLS, the search will be
quite deep and the cost of using a hign-entropy hash like MD5 would
quickly pay off, whereas if you have only 100 URLs it would never
pay off compared to a plain linked list.

I know red-black trees are all the rage these days, but I'm not
convinced they are the silver bullet for us.

If we use a high-entropy hash function like MD5, there is no need
to do red-black, a simple binary tree will be better.  Red-black
tress shine when your keyspace is lumpy and/or sparse, but since
md5 hashes are dense, a strict two-branch binary tree has less than
a quarter single-branch nodes when populated with more than a few
hundred MD5 outputs (I tested this up to 10M).

But mostly, a red-black tree does not offer us a way to distribute
locking over the tree unless we put a lock in every node, which on
the other hand would be way too expensive.

One very interesting and simple idea we may want to try out at some
point is a tree (of some kind) indexed by the URL read back to
front.  The idea is that the closer we get to the tail of the url,
the more information there will be.

For instance, if practically all your URLS look like:
	http://www.myplace.xxx/article.php/id=#######
there would be very little point in bothering with a hash in the
first place: what we need is right there at the end.

I fear that the object lookup may be a significantly interesting
performance hotspot, and I can see so many creative things one could
do, so I have decided to wrap the "URL lookup" facility in a named
API (struct hash_slinger :-), that way all you have to write is
three functions (maybe four if you want to report stats) to try
out a new idea.


-- 
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 des at linpro.no  Tue Apr 11 09:33:11 2006
From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=)
Date: Tue, 11 Apr 2006 11:33:11 +0200
Subject: hash algorithms...
In-Reply-To: <54984.1144743270@critter.freebsd.dk> (Poul-Henning Kamp's
	message of "Tue, 11 Apr 2006 10:14:30 +0200")
References: <54984.1144743270@critter.freebsd.dk>
Message-ID: <ujrlkucv4mg.fsf@cat.linpro.no>

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> I know red-black trees are all the rage these days, but I'm not
> convinced they are the silver bullet for us.
>
> If we use a high-entropy hash function like MD5, there is no need
> to do red-black, a simple binary tree will be better.

True.  The hash distribution should be good enough to keep the tree
balanced.

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


From phk at phk.freebsd.dk  Tue Apr 11 10:47:30 2006
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 11 Apr 2006 12:47:30 +0200
Subject: Figuring out VCL 
Message-ID: <56019.1144752450@critter.freebsd.dk>


Does this little flow-graph make sense ?

	http://phk.freebsd.dk/misc/vcl.pdf

The three boxes are the three places where VCL code gets involved and
the contents of the boxes is the default VCL code.


-- 
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 andersb at vgnett.no  Tue Apr 11 22:34:14 2006
From: andersb at vgnett.no (Anders Berg)
Date: Wed, 12 Apr 2006 00:34:14 +0200 (CEST)
Subject: Figuring out VCL
In-Reply-To: <56019.1144752450@critter.freebsd.dk>
References: <56019.1144752450@critter.freebsd.dk>
Message-ID: <1434.193.213.34.102.1144794854.squirrel@denise.vg.no>

>
> Does this little flow-graph make sense ?
>
> 	http://phk.freebsd.dk/misc/vcl.pdf
>
> The three boxes are the three places where VCL code gets involved and
> the contents of the boxes is the default VCL code.

Great.

Yes, this makes sense. 2 questions:

1. From box 2 you have a error "arrow", is this for when a request is like
"GET /%#!! HTTP/1.0" <- chars that are not allowed?
2. The "Pass HTTP request to backend" points to "Request completed" when
there is a pass. Is this done just to simplify the flow-graph? Varnish
would get involved in delivering back the document anyway. This maybe
outside the scope of the flow-graph, but I thought I'd point it out
anyway.

Other that that, I find it a correct representation of what we have
discussed so far.

Anders Berg



From phk at phk.freebsd.dk  Wed Apr 12 06:28:59 2006
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 12 Apr 2006 08:28:59 +0200
Subject: Figuring out VCL 
In-Reply-To: Your message of "Wed, 12 Apr 2006 00:34:14 +0200."
	<1434.193.213.34.102.1144794854.squirrel@denise.vg.no> 
Message-ID: <60575.1144823339@critter.freebsd.dk>

In message <1434.193.213.34.102.1144794854.squirrel at denise.vg.no>, "Anders Berg" write
s:

>Yes, this makes sense. 2 questions:
>
>1. From box 2 you have a error "arrow", is this for when a request is like
>"GET /%#!! HTTP/1.0" <- chars that are not allowed?

It indicates what happens if the VCL code executes an "error" statement.

In the default code we don't use that, but the user might in
customized VCL code.

>2. The "Pass HTTP request to backend" points to "Request completed" when
>there is a pass. Is this done just to simplify the flow-graph?

A better wording would be "pass-through" I guess.  Yes, Vanish is
handling the data forth and back, but is only acting like a relay,
it doesn't inspect the transaction further.

>Other that that, I find it a correct representation of what we have
>discussed so far.

Great, lets see if I can get it to work then ;-)

-- 
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 phk at phk.freebsd.dk  Wed Apr 19 09:48:01 2006
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 19 Apr 2006 11:48:01 +0200
Subject: Something to think about in the plane
Message-ID: <78451.1145440081@critter.freebsd.dk>


At this point it looks like the most nasty stuff is actually
interpretatio and generation of http headers.

Here are some questions you guys can think about in the plane
on the way down here:

*  Which "Host:" do we put in the request to the backend ?

      The one we got from the client ?

      The ip/dns-name of the backend ?

      Configurable in VCL backend declaration ?

      (test with www.ing.dk)

*  Construction of headers for queries to backend ?

      How much do we take from client headers, how much do we make up ?

      Some sites discriminate contents based on User-Agent header.
         (test with www.krak.dk/www.rs-components.dk)

      Cookies

*  Mapping of headers from backend reply to the reply to client

      Which fields come from the backend ?

      Which fields are made up on the spot ? (expiry time ?)

      (Static header fields can be prepended to contents in storage)

 
*  3xx replies from the backend
 
      Does varnish follow a redirection or do we pass it to the client ?
 
      Do we cache 3xx replies ?


And here is a new version of the VCL flow-chart.  There are now two
versions of it a "user" version and a "real" version.  The "real" version
goes into deeper detail about object handling, something the user will
not need to know about normally.

begin 664 vcl_flow.pdf
M)5!$1BTQ+C(*)<?LCZ(*-B`P(&]B:@H\/"],96YG=&@@-R`P(%(O1FEL=&5R
M("]&;&%T941E8V]D93X^"G-T<F5A;0IXG)U9RVY<QQ'=SU>TM;&\4*>KWPW#
M"QM6(@,*$,DTLC$04,-+D_:0E/C*(LZ_YU3=?MP[5A+<D2"17=//ZE.G3O5\
M4D:3,ORW_MS?[#[M_O3>JU\>=N_P*]MN\'\JUJC#S@>W_IU_N=K]7=WNHHXY
MJG_N2/T5_ZYWSE#1):L48M0^8A:;;-`PQ.)TP#A++FGOAH&R=]J&/F31Q;O"
M/P]]DFZXVOVX^Z1(#M%^[&_4=V<X1E%%NVB\.KO<S><C98W1`3,&IYUQZNQF
M]_+]M)^NGR?UYNSL;^I^^O0T/3Q^=?;K[O69>K<C$Y..2<50C'88GVS2N:B0
M,^;.Z/\_-D#TF1T0D?8^J62B#H9D"Y=/MWOUO#_\XW[:/ZM_\>ID="PIJK.W
MNY=*J>M+]?-+;$[CG_KB&_7B+Z_/7JC??U=+VYO7WW[_XN>O,,&7, at A_/IX_
M/'Q=F__FG_R?G,QZ1SI:]J75R?,--8M+1=NH1INL]J-I?=#!JSU.CE_9#]VV
MF(12!B;XSCQ.'$:?P^[RQ'%\V3;%H(M5D:S5M at BPF@5WDH*RD:*V7D7KK8YC
MWZV]WUGKHRYE]#`E:;>8H;?G-3"B64P`_JSJ,QA#NBS6J&V,:+MH/=HNVPQ'
MY]AO!3)E;1)AOJPS0H]A]/;N[K>GC^JG]V\[?OO&*GZ'HZ,O4:>Q<X>FIT7;
M%(3E\I*K:3%%]=^XJ]IE><5;1FV.9LP4X+SHL!1_Q+%T?7O]<#4".$2`%_ZW
MN$&&2S=X7`S&DJ>@$Z,]!]`@6>?E?N;F'H$(KD#$5T,Q25N3^_#>GN??[[J!
MBL>A^G"2B![SUS86:!MH/=H&ZP3K`VS%"8'P"N,/SD\EB(M^>'AXFOE.F`94
M6$!(KSKE7.Q>3O?W=_?#B3X#I`L0$3:M+8,H@,6*RAX?^(R[S84WV]L=W<>6
MUG8V&H[W9_1(VCCLM"`A(')*\MK@$YN02HA/DDGC<#;@ML/L";B,<"DV@")L
MEHV1UYYA#1KQEM.*B>P!]$'JL%:P>=*PK>#,3D?GE(].DYMY?NU5EUR`ZP<T
MNZ%BRX7H%]!T+GC>;H>F(V3,3,V`:;#4@&9O-^1TPXRL/KP"K\_?H=DWT'JT
M#=8)U@?8"DW'D<)Y9@'--^>W%X=IF8:1K\GSQRM\GC](:GN\NK][^F5$.XX$
M$"V1ZG at 5QIV/$"11.8_X"\QOP&%.H]V1>FQI[8'4;JDBQWFLD8">%"QG*N<R
MVHPO4&"<2;3WJ3;>&>/9X;H*GQ\(<X[%1NQ]&*JGC=N*59P(Y!]78&7_#@9(
M#NDL*9\Y^+(B5P01!<QMX=83=%!BSDXJ8$EOCW308<YD_U4)?7'WX5=]>?=T
M>[&6.Y?3X_YJI7=6(_;G^ZOS#X=IJT9J27PDL5`\B"+T=`D]F.?8;&T02G*K
M_-ELBUD2X`H0CE38^BPSZ+9Q(I(J:7EK757?S<)08:)SH+Y(ROOLV6[),MOV
M-M)2,0#SZ$$)X5#Z!*U95T#_:C`0CW!,&PY98246Z@*M#3:J6^@]VA;K#,>'
MV*R0L`$#@'E;=*I"^\^,#P;5*ZBS%)&I5JPB)<#5='XQW0OT"0 at E<Y0:+^_O
M;M2'\_UOT^W%T%DS!;;P@,.1MC0%Y9/WNB16C)[U%2*,&9DD8'T(".4\H\2B
MV$DX;D!')\*6,.?BC@[#$D)B7A:4G#1NL]+"7:2\SF:7S9DS0Q1P",AON*`5
M=#XQ:H$8J+7"'`/(PDR1[QU3>E!)%T(0`)YP8Y"TY"`R,O"`9@#BD.8T at 8]9
M\CIF5:)(''0.DH!S-6$)YC^;;=2&M1;"EO/3 at H=!ZC2CJ_$I>F4MBJ[Q*1$8
M%JE[R<.GC=OJ9CYY`C`<#I)3_(QHL!G%&%_W0%KF`@Y^2B5SG-B,+,17E9@^
MH)=RLJQ`?4+)8)F2()6C>-X!.N3@/^>8WAR+10#&(8UJ2NO\Y9#SK%OE(93"
MP2_SD(4L(,E[Q#<M^>ND<9OS%P<H9]Z%WU;Y"ZFY\#8HX-**E"/-$H/`$MG=
M"<P2A`(KP9E8:Y.+1B1[+-$^-U%T?1_>VG4!KAFKQ4%$L0)O$U0<]Q5JFVO&
MNH76HVVQS7!TB,V,",<3F!PW`>>+D[Z?#M?/D\#K%?C)(II69'=QMW^ZF6Y%
MB;UB69ZAKOY(ATBNTWZ\FMC()7M:@K2*>!]QQ8ZE$K\Q`)3>&89B;W>R/[:T
M=F7:Y]ZA918;2^&?5"!5LKP#9*ZT*'%E6TM9KA1S9O'A4#Y+8LRB89O``5D&
MQ!$4%V7#7#>3[$GC-I-L2B*F6)HF&SY;SCHF/_BOH&PS4JY*R,;"U.E/T6'8
M/V46QLBZL:QUF%#\_Y%AS^>'ZR,9)I3U!QEV^S#=/WZ]%E at F&09*TP#PJT&*
M`@7E%)@<K,'Y/!-BE,L$HZ.-'("/+<UWVKI$=`DLDZ at 4+B5[ICBPA<O-/D[N
M]*1Q?*<44Y1Z:[X#?E-`?>PY8`$*)/M:+[<P("[(6`,$),(R[YJ`:U'Q@=KJ
M#MDLQV4-RDJ_C#I5\M!)XS;G(5P"L?OE>OSG\I!G75,63K`1O"(LA7S#:2A'
M>45$':4)+C0QRHU6VI>D8M`G<TEO4,"R3G6$U,UTZL$3D</*<2'.-2[T5!7&
M)PW;'HSP'3MQX8*C8&P>[P5\-W at _7X!#<HA#@#0=-A*K-?*$U2U4J'IIGJ&W
M6XG=#53?E=H$AG.Y'TO4-NOLNHG6HVVRS;`^Q7:9#6+G9QF9??;3#Q+JDC/`
M[IE".4H:(U\@ZQA`XBCM7-\JKM6FX6H#4DW+F(.\=U(85_D#XN"G at IXD&[78
MB)B,67S-_,J(C+!PCRRRIY$[3F+$7A.'D$M]^;`1`CC(NLW2Q<I8:4:ZD,M)
MX[9_F\'?NZ051J^[[V?'%21>+)MQV9"-'*;SZ4O&U<BSNN5H!WL-"XHW+LK;
MH-$EV?F+GD.?9EBV;SYH#_T,JH3"KU_%R+./VM_=?#Q,C]/%(N]QO2UO4XGS
MWPV_26:15W6OK;R@``UMY)L>00S4`?$-+`09^%O(HGZ]1*;X.0",EQ=APY*U
M?L&!NHU3`1`N8<6%'==0&=Y*_-(IQ97AEWPRK)IS+<I.&,8.=)8OP?<7-Z:V
M+"*=,OJ;T!^=*-",XHRV7QZSJ<1VS%@LNZP?,SI.3JM3MD15]\+R!J0`[XWM
M5I"V$\VJZ(1A\CXQI"_5Z&B65D+U=GN8K6T3X-CZK,*O_LTRIAAK.V2:T#K,
M+RH;A\AF<4S9 at N'G4AEFL[S_ at 6JCY'445/(H5J%H'6X_XM`9VBK,+Q<6ZDRG
M;L(D#GMA!3?7$[QVG25S^5MQ=,(HWO,[_/T/4L,7(V5N9'-T<F5A;0IE;F1O
M8FH*-R`P(&]B:@HR-#@S"F5N9&]B:@HQ-2`P(&]B:@H\/"],96YG=&@@,38@
M,"!2+T9I;'1E<B`O1FQA=&5$96-O9&4^/@IS=')E86T*>)RM6MN.'+<1?9^O
MZ/@E\H,ZS3L)(P\.[,0!'"!V-O"+ at 6`U&GG7GMF5]R(AB//O.:?(8G>/;<$]
MB(3=V>*PR&+QL&[DC\,TFF'B__:Y/^U^W'V%'Q(G_$[%3L-QYR>S_IM_W.R^
M&>YV?@PY#N]W9O@;?FYWUDQE#'%(<<JC21C%E"F-*:&EA-$9<)HP^=&:98N;
M[.AMYUKT"=:,DV>+CM-;;G;_V/TXB#B3?NQ/PY^N=G_XN at P1`Z+;U9M=79P9
MC#>C"QPAC\'BJ]/NQ=>'_>'VW6'XXNKJ[\/#X<?GP^/3QU??[SZ_&K[:I32-
MWL<A%I?':`>3$Z8N at Y\<UIC1_P,2&/,+(N1IM,'G(5E^9T6$-\]W^^'=_OBO
MA\/^W?`?SIY&YU(<KK[<O1B&X?;-\.T+R#;B9_C='X>/_O+YU4?#3S\-R[8O
M/O_TLX^^_1C\OQ<F_'M[_?CX22/_RT_^DH69-(6Q%&C"0([`7=(6G\J(J6?:
MN;',I,N9RM]CX299#SE[VV(0Y^UH,C<M%CO:N<]Q]^9"/FZV*2Z,%EL;31JC
M8$L;HAL-Q,S.CM$-,4W`M.]B*[T'KK`^%^8>/L4Q+D;HM$P!!FT(R8X30*0#
M!$P]A7F*1H-#A=`>*J2.L%[%?BN*@QM=YG!E]#$)A+Z\O__A^>WPSZ^_[-CM
M<C7LSEJ..?G1FUGRC$^BNRO+Q]4&2\."OZENWB7IL-S:W\JQ^03C0)K(W2MC
M!&[E^-S>W3[>S.MV,5+[!M@>LT!;6[*U-"#&@IYXFGD:`77:A6(ZC1V<L#-Y
M;BD at 3<E]A$ZW.?:[W@)EC at 5SZ0C1.IB0>8Y&8PZ50GNHE#K"V3JVPJ1D'&/A
MC[!51E3UU\?'YVKJJ*Z"HY9"&%ZJM7F]>W%X>+A_F'4Y374[.X9R!J0++&*.
MTXB-R+#;M&<Q!3$;G59LGS4H:2U..N9^USNHX\@96YNAEY+-:,)0('\VV*5<
M//5%/11(43*TW5S"B9+FL7!/H^CYN"LXSU/@GF4_YFIY+N/;"E+LGW<I#QY*
M\[9J?JU79WD"NQ).O<$98"$-#D9F=`DT\`YMN\FX3NQW-L=,:&B+)41BYU:R
MC8[^K<'`>Y%-V0%*GLHZ>B/VNSZY?MUD:]QGLF^%I<6N%O!9"YOCJG*^N+Y[
M?3PLO>\$"^N,76/S^E$\VM/-P_WS=_.!M_#$,`H+D-H,*U020(IU`UIN\A,<
M?C4ZG5"$GC4H:5-V8P)`>P,-;N9H#F$$-!#@PX7&)T2$0 at S-*C72>5H;=GB"
MZ3"RI8%Z.^ZJVEL'HO,"IJW0Q!0X0VGP1`!\"+5/G<XGWN-D at -,66(TL!R3X
M$6".!N"J)KQV"<7BQ)-..#HXF'./S58="HS at C,9VJ;ZYOGT:WM_<'@^4[26!
M7;);X>'^U?>'_=-P^SB\>G[\][R$"--D9O>+-4231T2IT>.\X$B;@#,.$Q,=
MW(C!X0^&+K6O6GQ?L(FKB3:G46(47R:&2M$&!*VBAU*(MX@](?[$_UW`M5E;
MD:<#TKHR6N!/?.#]\]WK^428B+"\]!TYS2T61A8KQ0<<F5,Y+>W\E)6$<RHF
MP(AI@\D>`6_J[)UN$S#F:2T3`DILH0X0>"ASZC,H#:/41.@]5,0VPODB-H=)
M!7:\$+A1U"7^[^[Q\"`&QHS6!WB;)9X412\-`(_9?P%LB^BJ>N4%R!(F!)@Z
MR%0CCG;$=/^%C0]CJH93_1`,X40_RX`6XA;B!:OW<KQ:#*+@%)A=Q+<9:-G"
MNY05T.[NGX8UV(R/EO$*SI#A?A:$ISD32PYA<[P at 1\(1&<.$$2,6Z=,Z1SK6
M2/?7LJ3?89]&$7"="KTY/.UO5KG0BF-_O;^Y?G4\_.;\J5F,4!`D)-F``#N)
M@*B911Q2AC%#8)PD<1_V)=D!R8,E2F3W8\K<JY!A"I`/G'IT'!"6\?0P7@[B
MXD/B9K3\Z2*^FC\A`$J^GSGBID99(9?$TV:*A(N@@^PF:/CKW.?:+T>9YR_8
M*E>6\Q?DV,AOM4]%[25\E-NB(W,P'*U"PWV:6S+B-_C>"6+"S'H@;T1.I,=!
MZ3V]E%WU@/$?K?(KU<9']]8`Z\/TLW,'-S&RZ.,WFN:L2=!:NH!MA/,E;#9G
MR!UA19B,TH'S3+`F\/9XO3\,LW&"]V&<LC)=[V^?;H:[P_OF2(NU9XZ4AJ^-
M\>W'"R\"VX]PQ)M)3,II;K&3&Q&<V2E*>N`QX. at 8LL.!N]AIT?K$#>X]FEK;
M`$JV&6:U3\Q(676H[*XP6C1]`J6I]BJ"MG01VPCGB]BL=IQO`UODZ<Y*#5?_
M3%M2'06VO.2N;2O:E$K2S>'Z]>'AL<:RN5B/Q2]5_N;A_C2\NM[_<%B:THXJ
M!$0N+\RZ]U%BS*YAA^-:<=AHY^@0ZO$$`E-ODD%T6U+-<>"+B'KM4 at _G=JZ;
M>3:U_J?>,.%H!QH0K`4&+TQ3PTBE?7&E&T+^#9>A;1P$$2ZX?893M5$,0Q.G
M]6DR7\"WV0T6Y#V%LR!3#,T=*036+I#.MRK!0D>13M$3-RP'(!C`$,SI?2=G
M<[-N:.2<)&N#<;8.YRO:I<K`\9+$'JI<4>J4)3UI^W&:&UI@<&1L7Z@;U9KH
M]!*VS2J=R(A3RW*?";^0(5O/*!"PL4',*8Q/1&B-1$21AB1/Z at 6^!$OY.MV5
M>MZB=,_L>@.=96)NBB5.^*1W9YY%H\+0U!MQKU2K)8[B,DFSQ4NE6K/Q(UH,
MUX4^"--B$+U>QK=5L9;>'EFU2\`%,IZ?Y7>6<0BR8'@)\?NGN<5A5P%B)"J)
M`8SW$X65^IT04"A$IE.NWS7+VOF4;B/ON[LP!L>#!05EGR`E/OOHC09'FUL[
MJ&@ZP)GPFVL/.#TE462RUSSSL\/Q]MWAH?G&R;DY[J_F_/7]_OETN!/O^A)B
M`3WQYZ;\+#W0'9S-HE8+`H\L$B'+G!38S$DB>"5G\*X;&JEIQSO]'G%>&`.+
M$3BE<*@!2)Z at J0`#`<3",LD6"'(#0BO9S&JM9IF,QZ=ED&@#Y/6I5\$%N1?Q
M;48NMM0CL'$37-^O5'9;+NWL)-:/"5;&])P39^F23",PJ/*#BQRXK#,-L?$?
M3C3>71]OSQ(-,6,_2S0D[_QDG4+,L0P"1+?PN(ZU2+^(=I at S1+N@+0N+2V>O
M38M!(LY0B+/;UBX+9[^)2^+P"7;%=PMZFALR^#R]!C4)N)8HGLL at CV9ZK#0C
M/)81R]RCY4U]!*7K%/N>6-F(4(R56AT@(J++BRD:S>)%$Z*U="';"&>KV!Z)
M0W>T3N#VS7E]>CS>[Z^?#K6T$*=@5B;B\>G^X?J[6LE",.5 at YM8FY/YA6-J9
M"I"<`C,5A3MV*4<><L>[!.(CLU`++SJEBH_LI1#J6--NA4BM:VO;J5=J=`.X
MU8X57>TB`+F$;7M]`>;?K8_\;:_0-#N*(V\7>&MT)B;H3+'W%L94':>#1S&=
MI,?B[:6=.R`OG[F%4!`T"OT2KR<:'\TK][H-W,C]KL^L'530QK^2>[.?L at A>
M'0%:1I:LJ9CG.RU/T4[F8#]4G4)6Q'EGY%@#;P$_Y%A,D^):RKS$=/1&,'P6
MH:;$(BU*$7^!P$0RV0)8,1FQEC4!*G-J-05KC5AD2WOB6Z!S"=MF;V&P at PB$
M/^@M<"K,#!VEV^8;!_MF2D>&P2F2V*]CQUCD?-G-/=H57A]!Z6ZI>D,%01^@
M8:1/T5'4A=`>*G,;8+6$S7;*5H]Z,8JTJK0P0+!L$,CQJL[1?>+H)^X"<KO,
M:,.%:OUKW"P&R'LIXZH6N1',!"7:+NVRGS%QC,1#Z(\$+N*[I)8>BUOAZ"P1
M2<DSR<E&0,QX>9(\B/X12!`X5X`O6IJ':4QS%UZ/\[W,L0\SMVP_`YF!9&(E
MK[2W+'*!-NSO3V^/AZ?#HK)@LY3?3?21D33KE;;ZWX8Q6G&6Q7CIQ]N]&.B-
M>4!+B,T>)''$3%M2O57 at JQV3AC+)#;8L,W*+]#:\VH,+V&[D#JVB2B^&F3$E
MZ:=7LVI1#/,S6`/+YP9)TN'$?(Y1-!)C2;@MKY8&32+U4KF%S<1/\!HF%W&[
M#,M2%GF#+[S+G^7E0P[,HTNJ4?(%;!)3]2RH"GU:M+C(JJC2!3XE at +_3&+\E
MI3PLSK>6>81YZI;!U at XB[U86D=5EJ6+/%]>]Q?%ME2-PDBBZI;G66"G[S)>C
MIB3647J+AAHZ0J?[!7-O at 7V1]QLZ0O5R?8I*TNDW&=KW*F)C/U_$9N\\01K&
M!I:*6;PA:QFBL^O@;Y5`PDX!'>4WU0(E(D=>)-=&IU[MLKR]#*F7YFW`EHDZ
MZA6;]0'?U_!/"T1HRWRXQHC=5B?4MI<5,N!*MJ at B0M!Q$9_4`V.D6F:$:(-N
M;T#.1:^DVU]ODQ?XL%S>?,D-@\0CVOD;.:.C-2 at XE+UNO@ZOV.C3MZ^;<,J\
M%GZSQX6US%-<(..SV\?]]</KAHR8F#?\'[#A$'P:`AP&I5[C6-YJ\![$RCM*
M0XL:6**K%RQ:C]1ZLGAFZ^MW\V,8QF5IT,3CR(;""58%PDO8JJ$#?E-8/,SJ
M+>U9%6)>"9BTU*BN8WZ8!9\G3UQZC^8;^@A*]T=3O:4]J^HCM&=7?8[^,*M+
MH3U42AWA;!V;[8=AS&=6#[.V1?<M>&\8ELNPFMWHJ67`EN-L(;@?<5T>E at S'
M+>J\O:'7>>=AYMV_B*VZ#A/D65O3*EV'Y%0FY/;&Q==W<"PEB4<)O`HR/LMH
M(G.KE&HAZ+1H\7R2W,?PV3`[$XFW,]TL7*J-171(?QXD--*J`ERX>"6R3<Q)
MD0X;&JHLST]$8";--)&N2-K%ITE\'4!S&"1G/_;'2I;O_5R]C+F,3\RO@^TI
MOF<4?/W(BP]F'37 at -!R!16TMV;5WAI:E0MN"=JZ!ST1:&T?!X<Z+ET=]&%8%
M8WN6<`D;I?X*__\''^9_UF5N9'-T<F5A;0IE;F1O8FH*,38@,"!O8FH*,S8W
M,PIE;F1O8FH*-2`P(&]B:@H\/"]4>7!E+U!A9V4O365D:6%";W@@6S`@,"`V
M,3(@-SDR70HO4F]T871E(#`O4&%R96YT(#,@,"!2"B]297-O=7)C97,\/"]0
M<F]C4V5T6R]01$8 at +U1E>'1="B]%>'1'4W1A=&4@,3(@,"!2"B]&;VYT(#$S
M(#`@4 at H^/@HO0V]N=&5N=', at -B`P(%(*/CX*96YD;V)J"C$T(#`@;V)J"CP\
M+U1Y<&4O4&%G92]-961I84)O>"!;,"`P(#8Q,B`W.3)="B]2;W1A=&4@,"]0
M87)E;G0@,R`P(%(*+U)E<V]U<F-E<SP\+U!R;V-3971;+U!$1B`O5&5X=%T*
M+T9O;G0@,3<@,"!2"CX^"B]#;VYT96YT<R`Q-2`P(%(*/CX*96YD;V)J"C,@
M,"!O8FH*/#P at +U1Y<&4 at +U!A9V5S("]+:61S(%L*-2`P(%(*,30@,"!2"ET@
M+T-O=6YT(#(*/CX*96YD;V)J"C$@,"!O8FH*/#PO5'EP92`O0V%T86QO9R`O
M4&%G97,@,R`P(%(*/CX*96YD;V)J"C0@,"!O8FH*/#PO5'EP92]%>'1'4W1A
M=&4O3F%M92]2-"]44B])9&5N=&ET>3X^"F5N9&]B:@HQ,B`P(&]B:@H\/"]2
M-`HT(#`@4CX^"F5N9&]B:@HQ,R`P(&]B:@H\/"]2.0HY(#`@4B]2,3$*,3$@
M,"!2/CX*96YD;V)J"C$W(#`@;V)J"CP\+U(Y"CD@,"!2+U(Q,0HQ,2`P(%(^
M/@IE;F1O8FH*.2`P(&]B:@H\/"]3=6)T>7!E+U1Y<&4Q+T)A<V5&;VYT+U1I
M;65S+5)O;6%N+U1Y<&4O1F]N="].86UE+U(Y/CX*96YD;V)J"C@@,"!O8FH*
M/#PO5'EP92]&;VYT1&5S8W)I<'1O<B]&;VYT3F%M92]4:6UE<RU2;VUA;CX^
M"F5N9&]B:@HQ,2`P(&]B:@H\/"]3=6)T>7!E+U1Y<&4Q+T)A<V5&;VYT+T-O
M=7)I97(O5'EP92]&;VYT+TYA;64O4C$Q/CX*96YD;V)J"C$P(#`@;V)J"CP\
M+U1Y<&4O1F]N=$1E<V-R:7!T;W(O1F]N=$YA;64O0V]U<FEE<CX^"F5N9&]B
M:@HR(#`@;V)J"CP\+U!R;V1U8V5R*$=.52!':&]S='-C<FEP="`W+C`W*3X^
M96YD;V)J"GAR968*,"`Q.`HP,#`P,#`P,#`P(#8U-3,U(&8@"C`P,#`P,#8W
M,C0@,#`P,#`@;B`*,#`P,#`P-S(P,B`P,#`P,"!N(`HP,#`P,#`V-C4X(#`P
M,#`P(&X@"C`P,#`P,#8W-S(@,#`P,#`@;B`*,#`P,#`P-C,U-"`P,#`P,"!N
M(`HP,#`P,#`P,#$U(#`P,#`P(&X@"C`P,#`P,#(U-C@@,#`P,#`@;B`*,#`P
M,#`P-S`Q,B`P,#`P,"!N(`HP,#`P,#`V.3,Y(#`P,#`P(&X@"C`P,#`P,#<Q
M-#0@,#`P,#`@;B`*,#`P,#`P-S`W,R`P,#`P,"!N(`HP,#`P,#`V.#(W(#`P
M,#`P(&X@"C`P,#`P,#8X-3<@,#`P,#`@;B`*,#`P,#`P-C4Q-"`P,#`P,"!N
M(`HP,#`P,#`R-3 at X(#`P,#`P(&X@"C`P,#`P,#8S,S,@,#`P,#`@;B`*,#`P
M,#`P-C at Y."`P,#`P,"!N(`IT<F%I;&5R"CP\("]3:7IE(#$X("]2;V]T(#$@
H,"!2("]);F9O(#(@,"!2"CX^"G-T87)T>')E9 at HW,C4R"B4E14]&"@``
`
end

-- 
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 andersb at vgnett.no  Tue Apr 25 13:03:35 2006
From: andersb at vgnett.no (Anders Berg)
Date: Tue, 25 Apr 2006 15:03:35 +0200 (CEST)
Subject: Graphic design
Message-ID: <1479.195.139.5.194.1145970215.squirrel@denise.vg.no>

Hi,

this is what the Trac page could look like with the new design. I am not
saying that we should/must change the trac design, but this is what the
page would look like with the Varnish design.


I think it is starting to look very nice.

Anders Berg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VarnishWeb_TRAC.jpg
Type: image/jpeg
Size: 222591 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20060425/5d2986e6/attachment.jpg>

From andersb at vgnett.no  Tue Apr 25 13:12:20 2006
From: andersb at vgnett.no (Anders Berg)
Date: Tue, 25 Apr 2006 15:12:20 +0200 (CEST)
Subject: Graphic design
In-Reply-To: <1479.195.139.5.194.1145970215.squirrel@denise.vg.no>
References: <1479.195.139.5.194.1145970215.squirrel@denise.vg.no>
Message-ID: <3771.195.139.5.194.1145970740.squirrel@denise.vg.no>

Here is a version that really takes the washing detergent look to the
extreme.

Just so you know how that would look. :) I am gonna vote for the
conservative version. Hehe.


Anders Berg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VarnishWeb_TRAC_02.jpg
Type: image/pjpeg
Size: 247339 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20060425/8362b6ff/attachment.bin>

From des at linpro.no  Tue Apr 25 14:21:30 2006
From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=)
Date: Tue, 25 Apr 2006 16:21:30 +0200
Subject: Graphic design
References: <1479.195.139.5.194.1145970215.squirrel@denise.vg.no>
Message-ID: <ujrfyk1u45x.fsf@cat.linpro.no>

"Anders Berg" <andersb at vgnett.no> writes:
> this is what the Trac page could look like with the new design.

Unfortunately, we can't easily change the design of the Trac page.

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