Re: [squid-users] Squid-2, Squid-3, roadmap

I believe that we have to look far past the current Squid-2 and Squid-3
versions and think something much .. well, "better".

My initial Squid-2 roadmap proposal (which is still in the Wiki) aimed
to take the codebase forward whilst beginning a modularisation project
(which is in there; just read between the lines and look at what
direction its heading in) with an eye towards pulling out bits of the
codebase and reusing it in a "next" release.

Squid-3 has done a little more modularisation work than Squid-2, but
there's still a long way to go in either codebase to properly disentangle
the dependencies and being reusing the interesting and useful parts
of the Squid codebase externally.

In parallel, I was planning on working on something which ties together
all the current best practices from HTTP software that, quite honestly,
smokes Squid in the performance arena. Varnish, Lighttpd, Nginx are three
examples which smoke squid in raw performance - but lack in features
and stability under given workloads.

Now that I have some support customers and I'm slowly working away at their
requirements, I'll hopefully start to have time to dedicate to Squid
features (to keep them happy) and work on the above in my (paid) spare time.

Adrian

On Mon, Mar 10, 2008, Michael Puckett wrote:
> I'll come back to one of Mark's earlier points then which seems to have
> been lost. What will decide on adoption of -2 or -3 is the "killer app".
> Developers roadmaps or sponsors notwithstanding. I think the point was
> raised that neither roadmap was especially compelling or seemed to yet
> contain that killer app. So momentum is on the side of -2. Users don't
> care if the project is recoded in C++ to make the developers life
> easier, the developers do, so that is not compelling in the slightest as
> a reason to migrate. Which I know you already realize.
>
> IMHO I still think that Mark was right that (at least one) killer app is
> a true multi-threaded application that can take advantage of current HW
> today. Now. I think that the current squid is exposed and probably
> vulnerable if a competing project comes out that takes full advantage of
> current HW and significantly outperforms todays non-scalable squid. If
> that happens the entire -2, -3 argument is moot. Just my $0.02 though.
>
> -mikep
>
> Adrian Chadd wrote:
> >On Mon, Mar 10, 2008, Alex Rousskov wrote:
> >
> >
> >>>WRT responsible sponsoring: I'm willing to pay a (reasonable) premium
> >>>to get the things that I pay to get into -2 into -3 as well,
> >>>
> >>Thank you, and I am sure many sponsors would do the same if the
> >>trade-offs are explained to them correctly. Unfortunately, I have so far
> >>failed to convince the most prolific Squid2 developer to accept this as
> >>the default model and encourage its use.
> >>
> >
> >Because I'm still not 100% convinced that the Squid-3 codebase is really
> >the "way forward".
> >
> >I shouldn't have been the one that tried to pull some sensible direction
> >and
> >feedback into the development group - those working and pushing Squid-3
> >should've
> >been doing that already. Unfortunately until very recently there has been
> >almost no public dialogue that I could see.
> >
> >My concern is about project direction and sustainability. I chose to do
> >my work on Squid-2 in mid to late 2006 because:
> >
> >(a) it was stable, so I didn't have to worry (as much) about whether bugs
> > were due to me or pre-existing code;
> >(b) it was in wide use by people, so incremental improvements could be
> > adopted by existing sites without as much fear as trying to push
> > Squid-3
> > as a platform;
> >(c) I wasn't sure at the time whether there was enough momentum behind
> >Squid-3
> > to justify investing time in something that may never be as prolific as
> > -2; and I wasn't willing to invest even more of my time trying to drag
> > the
> > codebase forward.
> >
> >I shouldn't have had to try and kick Squid-3 developers along to do simple
> >things
> >like regression testing and local benchmarking; I shouldn't have to try
> >and explain
> >that the model of "do whats interesting to you and what you're being paid
> >for"
> >is such a great idea as a project direction; I shouldn't have to try and
> >explain why an architecture and a roadmap is a great idea for a software
> >project.
> >
> >I doubly shouldn't have to try and convince the Squid-3 developers
> >considering
> >the -past history of the whole effort-.
> >
> >This is why I'm not all that interested right now in doing very much in
> >relation
> >to Squid-3.
> >
> >As I said on squid-core, my opinion may change if - and I stress _if_ -
> >changes
> >to the project structure and direction occur which I see improving things.
> >I don't mean "improving the paid project quota on Squid-3"; I mean things
> >like
> >improvements in direction, collaboration, documentation, testing and
> >communication.
> >
> >
> >>Personally, I would love to see active sponsors together with active
> >>developers agreeing on a pragmatic migration plan towards a single Squid
> >>roadmap. I would be happy to facilitate such discussions. The active
> >>developers alone have so far failed to reach such an agreement, but I
> >>think direct Squid2 sponsor participation may help resolve the deadlock.
> >>
> >
> >To be honest about it, the only dissenter now is me. I'm not sure whether
> >my
> >continued dissent is a good idea for the project, but thus far the feedback
> >I've received has been 100% positive. I'd like to keep kicking along
> >Squid-2
> >until the point where a future Squid code tree is attractive enough to
> >replace
> >it. And I'm going to keep dissenting until I see the fruits of actual
> >change,
> >not just the discussion of it.
> >
> >
> >
> >
> >Adrian
> >
> >

-- 
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -