Re: [squid-users] Squid Future (was Re: [squid-users] Squid-2, Squid-3, roadmap)

Chris Woodfield wrote:
> For our purposes (reverse proxy usage) we don't see any missing features
> from squid 3 that we would need - however, we'd like to see the code
> base mature some more before we trust it in production. Same reason that
> smart folks don't deploy new Cisco IOS trains until it hits the 3rd or
> 4th rebuild.
>
> However, I will use this opportunity to put forth my own wishlist of
> missing features (that AFAIK aren't even present in squid 3.0 at this
> time - if they are please let me know!:
>
> - Multithreading, multithreading, multithreading!

Pick a large number... ;-)

>
> - Better handling of cache_dir failures:
> What I mean here is, if you have multiple cache_dirs configured
> (presumably on separate disks) squid should not refuse to start if one
> is unavailable. It should scream loudly, yes, but should be able to
> carry on with the ones it can use. For bonus points, make squid capable
> of "dropping" a cache_dir that becomes unavailable during runtime.
>

Thanks for the reminder. I had some wishlist myself here. I've added
this and mine to the official wishlist.

> - Fix mem_cache bottleneck that effectively prohibits large files from
> being stored in squid's memory.
>
> http://www.mail-archive.com/squid-users@squid-cache.org/msg52509.html

Hmm, not sure exactly what Adrian as planned there, beyond changing the
underlying malloc/calloc system of squid to something else.
Added it to the 'undocumented features wishlist' anyway.

> - Allow helper children (url_rewriters, etc) to send some sort of
> "pause" message back to squid to signal that that child is temporarily
> unavailable for new queries, and then a "ready" message when it's
> available again.
> (yes, this is kinda obscure - the issue here is a single-threaded
> rewriter helper app that occasionally has to re-read its rules database,
> and can't answer queries while it's doing so)

Um, sounds interesting. I've added it to the wishlist. Lets see if
anyone picks it up.

>
> - A better mechanism (B-tree maybe?) for storing cache contents such
> that cached object URIs can be quickly searched via path or regex for
> reporting/purging purposes.

We'd have to find a tree that is faster than or as fast as a hash over a
very large dataset. Otherwise its not worth it to justify an overall
performance degradation for one or two relatively minor occurances.

>
> - Oh, and I want a pony.

Well... if you are willing to sponsor the funding of it that can be
arranged easier than most of the other requests.

Amos

>
> Thanks,
>
> -C
>
> On Mar 16, 2008, at 9:18 PM, Adrian Chadd wrote:
>> Just to summarise the discussion, both public and private.
>>
>> * Squid-3 is receiving the bulk of the active core Squid developers'
>> focus;
>> * Squid-2 won't be actively developed at the moment by anyone outside
>> of paid commercial work;
>> * I've been asked (and agreed at the moment) to not push any big
>> changes to
>> Squid-2.
>>
>> If your organisation relies on Squid-2 and you haven't any plans to
>> migrate
>> to Squid-3, then there's a few options.
>>
>> * Discuss migrating to Squid-3 with the Squid-3 developers, see what
>> can be done.
>> * Discuss commercial Squid-2 support/development with someone (eg
>> Xenion/me).
>> * Migrate away from Squid to something else.
>>
>> Obviously all of us would prefer that users wouldn't migrate away from
>> Squid in
>> general, so if the migration to Squid-3 isn't on your TODO list for
>> whatever
>> reason then its in your best interests -right now- to discuss this out
>> in the
>> open.
>>
>> If you don't think that Squid as a project is heading in a direction
>> that is useful
>> for you, then its in your best interests -right now- to discuss this
>> with the
>> Squid development team rather than ignoring the issue or discussing it
>> privately.
>> I'd prefer open discussions which everyone can view and contribute
>> towards.
>>
>> If there's enough interest in continuing the development of Squid-2 along
>> my Roadmap or any other plan then I'm interested in discussing this
>> with you.
>> If the interest is enough to warrant beginning larger changes to
>> Squid-2 to
>> support features such as IPv6, threading and improved general performance
>> then I may reconsider my agreement with the Squid-3 developers (and
>> deal with
>> whatever pain that entails.)
>>
>> At the end of the day, I'd rather see something that an increasing
>> number of people
>> on the Internet will use and - I won't lie here - whatever creates a
>> self sustaining
>> project, both from community and financial perspectives.
>>
>>
>>
>>
>>
>> Adrian
>>
>

-- 
Please use Squid 2.6STABLE17+ or 3.0STABLE1+
There are serious security advisories out on all earlier releases.