Re: Strategy

And in the meantime, if someone (eg kinkie) wants to work on this
stuff some more, I suggest sitting down and writing some of the
support code which would use it.

Write a HTTP parser, HTTP response builder, do some benchmaking,
perhaps glue it to something like libevent or some other comm
framework and do some benchmarking there.
See how it performs, how it behaves, see if it does everything y'all
want cleanly. _Then_ have this discussion.

Adrian

2008/9/22 Adrian Chadd <adrian_at_squid-cache.org>:
> Put this stuff on hold, get Squid-3.1 out of the way, sort out the
> issues surrounding that before you start throwing more code into
> Squid-3 trunk, and -then- have this discussion.
>
> We can sort this stuff out in a short period of time if its our only focus.
>
>
>
> Adrian
>
> 2008/9/22 Amos Jeffries <squid3_at_treenet.co.nz>:
>>> On Sun, 2008-09-21 at 23:36 +1200, Amos Jeffries wrote:
>>>> Alex Rousskov wrote:
>>>>
>>>> > * Look for simpler warts with localized impact. We have plenty of them
>>>> > and your energy would be well spent there. If you have a choice, do
>>>> not
>>>> > try to improve something as fundamental and as critical as String.
>>>> > Localized single-use code should receive a lot less scrutiny than
>>>> > fundamental classes.
>>>> >
>>>>
>>>> Agreed, but that said. If you kinkie, picking oe of the hard ones causes
>>>> a thorough discussion, as String has, and comes up with a good API. That
>>>> not just a step in the rght direction but a giant leap. And worth doing
>>>> if you can spare the time (months in some cases).
>>>> The follow on effects will be better and easier code in other areas
>>>> depending on it.
>>>
>>> Amos,
>>>
>>> I think the above work-long-enough-and-you-will-make-it analysis and
>>> a few other related comments do not account for one important factor:
>>> cost (and the limited resources this project has). Please compare the
>>> following estimates (all numbers are very approximate, of course):
>>>
>>> Kinkie's time to draft a String class: 2 weeks
>>> Kinkie's time to fix the String class: 6 weeks
>>> Reviewers' time to find bugs and
>>> convince Kinkie that they are bugs: 2 weeks
>>> Total: 10 weeks
>>>
>>> Reviewer's time to write a String class: 3 weeks
>>> Total: 3 weeks
>>>
>>
>> Which shows that if Kinkie wants to work on it, he is out 8 weeks, and the
>> reviewers gain 1 week themselves. So I stand by, if he feels strongly
>> enough to do it.
>>
>>> If you add to the above that one reviewer cannot review and work on
>>> something else at the same time, the waste goes well above 200%.
>>
>> Which is wrong. We can review one thing and work on another project.
>>
>>>
>>> Compare the above with a regular project that does not require writing
>>> complex or fundamental classes (again, numbers are approximate):
>>>
>>> Kinkie's time to complete a regular project: 1 week
>>> Reviewer's time to complete a regular project: 1 week
>>
>> After which both face the hard project again. Which remains hard and could
>> have cut off 5 days of the regular project.
>>
>>>
>>> If we want Squid code to continue to be a playground for half-finished
>>> code and ideas, then we should abandon the review process. Let's just
>>> commit everything that compiles and that the committer is happy with.
>>
>> I assume you are being sarcastic.
>>
>>> Otherwise, let's do our best to find a project for everyone, without
>>> sacrificing the quality of the output or wasting resources. For example,
>>> if a person wants String to implement his pet project, but cannot make a
>>> good String, it may be possible to trade String implementation for a few
>>> other pet projects that the person can do.
>>
>> Then that trade needs to be discussed with the person before they start.
>> I get the idea you are trying to manage this FOSS like you would a company
>> project. That approach has been tried and failed miserably in FOSS.
>>
>>> This will not be smooth and
>>> easy, but it is often doable because most of us share the goal of making
>>> the best open source proxy.
>>>
>>>> > * When assessing the impact of your changes, do not just compare the
>>>> old
>>>> > code with the one submitted for review. Consider how your classes
>>>> stand
>>>> > on their own and how they _will_ be used. Providing a poor but
>>>> > easier-to-abuse interface is often a bad idea even if that interface
>>>> is,
>>>> > in some aspects, better than the old hard-to-use one.
>>>> >
>>>> >> Noone else is tackling the issues that I'm working on. Should they be
>>>> >> left alone? Or should I aim for the "perfect" solution each time?
>>>>
>>>> Perfect varies, and will change. As the baseline 'worst' code in Squid
>>>> improves. The perfect API this year may need changing later. Aim for the
>>>> best you can find to do, and see if its good enough for inclusion.
>>>
>>> Right. The problems come when it is not good enough, and you cannot fix
>>> it on your own. I do not know how to avoid these ugly situations.
>>
>> Teamwork. Which I thought we were starting to get in the String API after
>> earlier attempts at solo by whoever wrote SquidString and myself on the
>> BetterString mk1, mk2, mk3.
>>
>> I doubt any of us could do a good job of something so deep without help.
>> Even you needed Henrik to review and find issues with AsyncCalls, maybe
>> others I don't know about before that.
>>
>> The fact remains these things NEED someone to kick us into a team and work
>> on it.
>>
>>>
>>>> for example, Alex had no issues with wordlist when it first came out.
>>>
>>> This was my first review of the proposed class, but I doubt it would
>>> have changed if I reviewed it earlier.
>>>
>>> Thank you,
>>>
>>> Alex.
>>>
>>
>> Amos
>>
>>
>>
>
Received on Mon Sep 22 2008 - 02:37:41 MDT