Re: client_side and comm_close

On Sat, Apr 19, 2008, Alex Rousskov wrote:

> > But now you have a better understanding of the bugs that are introduced
> > with AsyncCalls. You can then plan design changes to the client-side code
> > to work around these.
>
> I am not sure how to rephrase this so that it is clear, but client-side
> design changes are needed to fix client-side bugs, not to work around
> AsyncCall bugs. AsyncCalls are just a helpful tool here, not the focus.
> Removing AsyncCalls will not help but will hurt.

I know that client-side changes are required. We've all known that
the client-side codebase needs major surgery for various reasons.

> I simply do not understand why you focus on AsyncCalls in the context of
> this thread when this thread discusses client-side problems that were
> there before AsyncCalls and are there after AsyncCalls were added.

I'm not focusing on AsyncCalls. I'm focusing on the breakage that its
introduced in code which isn't yet ready for it.

> > Yes, then you left it by introducing something which exposed the bugs.
>
> The problems this thread is discussing were known before AsyncCalls.

But they weren't exhibiting as -bugs-.

> > Its great that we now know about the bugs - but now you've got a codebase
> > that you're trying to stabilise
>
> This thread is not about stabilizing client-side code. It is about
> changing its key classes and the relationships among them (for many
> reasons). This will certainly destabilize the code short-term. If it
> would not, I would not need to ask others opinion whether we should wait
> with that work!

I thought the focus on 3.1 - and I'd check, but the Wiki history for the
Roadmap stuff I put in early in the 3.1 roadmap cycle - was to focus on
stability and performance.

The recent work has broken the stability, and doing performance work on an
unstable codebase is silly.

> > If you back out the async related changes then you'll have a stable codebase
> > again - you can then make smaller incremental changes to the codebase
> > and test them to make sure you haven't broken anything, rather than spending
> > possibly 6 + months finding more surprises.
>
> I do not think we can fix the problems discussed here by doing small
> incremental changes. We are not talking about bug workarounds or a few
> places that need internal polishing.

And thats where we differed.

> > Remember, the initial idea was to use 3.1 to tidy up the codebase to stabilise
> > it, not tidy up the codebase to unstabilise it. Redesigning chunks of the
> > comm codebase -was- on my todo list for 3.1, but then people dumped stuff into
> > 3 to make it less stable again.
>
> This thread is not about redesigning comm APIs, and I do not know much
> about your todo list, but Squid 3.1 roadmap has been built in public. If
> any proposed Squid 3.1 features went against your plans, you should have
> added your feature(s) to the roadmap and discussed conflicts. This
> procedure does not guarantee anything (those who work together on the
> project have to compromise), but it works better than complaining about
> the first steps while approaching the end of the road.

_I_ helped start building the 3.1 roadmap, if you remember. _I_ helped
draft the notion that 3.1 should be about performance and stability fixes.
The introduction of AsyncCalls, whilst a good idea in the long run,
just shows that the current client-side codebase isn't ready for it.

> And nobody is tidying up the code to make it unstable, obviously.

But it is! And instead of backing the changes out - giving us a stable
codebase again, but with an understanding of what needs to be changed before
the AsyncCalls stuff is reintroduced - people still seem to persist along
the same path which brought all the quirky instability into Squid-3 in the
first place.

Stop thinking that I'm focusing on AsyncCalls, and start thinking that I'm
focusing on software engineering process with a lean towards stability.
If you want people to adopt Squid-3 then you should try and bring another
stable release out with IPv6 (once all of -those- issues are fixed)
 and without too much quirkiness, and soon.

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