Varnish mini status...

[Poul-Henning Kamp]

This is just an update to all our patient (and in some cases less
patient :-) users out there.

I'm back on Varnish now, after having spent a week on EuroBSDcon2007
and I thought it would be a good idea to outline what is going to happen
from now on.

The two big things are ESI:include, which we have promised our sponsors
will be finished Real Soon Now, and bugfixes.

Since the ESI:include stuff will be pretty drastic, seen from a
source-code point of view, I want to make sure we have a usable
-trunk version before I pull it apart again.

With respect to bugs, here is a little taxonomy:

    "functional" or "Varnish does something wrong"

	These are usually easy to reproduce and quick to fix, once
	we know them.  I will hit these right away once I can see what
	is going on.

    "stability" or "Varnish crashes after some time"

	Some of these will, upon examination, transpire to be in the
	"functional" category, but digging the evidence out of the
	logfiles to find this out can take considerable time.

	The remainder are often very time consuming to nail down
	because they are hard to reproduce.

	I keep looking for new clues to what might be causing these
	and as I work the source code for different purposes I look
	out for things that could be causing problems.  (memory
	leaks etc).

	However, there is little point in sorting the entire haystack,
	hoping to find a needle, given that I'm not even sure if it
	is a needle I'm looking for, so it is not productive to spend
	my full attention on these, until some kind of clue appears.

	I know it is frustrating to you to have a known bug of this
	class, but trust me, I am trying to nail it.

    "nice to have" or "I wish varnish could do this"

	Some of these are simple and will happen right away, others
	are complex and will be put in the ever-expanding wish-list
	and some are so big that we need sponsors to get through them.


About the <ESI:include> stuff.  One of the things which will fall out
of this is the ability to prefetch, it's essentially the same code
that will be needed and it is my plan to implement this first.

After that, there is a pretty major shift in memory allocation, because
we need to be able to "stack" requests on a session to implement the
nesting of <ESI:include> because the included document can also contain
an <ESI:include>, and so on.

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