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!
- 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.
- Fix mem_cache bottleneck that effectively prohibits large files from
being stored in squid's memory.
http://www.mail-archive.com/squid-users@xxxxxxxxxxxxxxx/msg52509.html
- 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)
- 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.
- Oh, and I want a pony.
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
