Re: eventual incorporation of push and hint cache into Squid-HEAD?

From: Jon Kay <jkay@dont-contact.us>
Date: Wed, 21 Nov 2001 11:17:10 -0600

Jon Kay wrote:
 
> > I would like to discuss the desirability of incorporating push into
> > the main branch once it is reasonably stable.

> If reasonably stable, isolated, solves some problem, not bound by any
> licensing/patent issues etc, then I am open for discussing a merge. The
> main point of collecting developments onto devel.squid-cache.org is to
> let them mature into a state that makes merging possible. Secondary goal
> is to not loose track of developments.

> If not isolated, then it must be tested to be stable and to not cause
> any measureable negative impact for people not needing the added
> features.

There are two cases here. The PUT stuff, which is three short and
simple files, using so far short and simple algorithms, in put.c,
dist.c, and webpush.c, is isolated. It only gets activated if you
use push, and it is relatively easy to stabilize.

The other case is the hint caching, alot harder. It is complicated,
and if people are to benefit from it, they will use the feature
frequently, anytime there is a MISS.

I propose following a merge path like cache digests: first I'll make
sure it works with tests I can run. Then, if/when I get to merging it
into main branch, the default will be to configure it off. Once it
has proved itself, we can change it to be default on.

Does that make sense?

> > The hint cache basically amounts to a distributed metadata system for
> > Disadvantages up front: push and hint caching are big, weighing in at
> > over 8,000 lines spread over eleven files. An operational hint cache
> > consumes 80-160M of disk space for Cache-Digest-like stuff.

> Key question: What is the impact for people not needing push and/or hint
> caching?

Good question.

Almost nothing for push.

If hint caching is off by default, then while that's true, then the
impact is quite minimal.

If hint caching is ever on by default, then people not running clouds
will see a slightly greater than cache-digest-like loss in
performance, and a waste of O(100M) of disk (e.g., a about a percent
of the average cache size).

Re licensing/patent issues, there are none. It is already GPL. And
we hold no patents. We do not believe in the value of patents to
startups, and we do believe in Open Source.

Just so people know, pushcache.com does have proprietary code that
makes use of push - a couple of programs and an application
development library. However, because we believe in Open Source, we
have worked to make the protocol interface simple to develop to -
HTTP+extensions - and document the that interface, and provid a
scripting program, 'webpush,' that lets people use push without buying
pushcache's PushAp Kit. We think it's easier to use push with said
kit, but by no means do you need it.

                                              Jon
Received on Wed Nov 21 2001 - 10:19:55 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:38 MST