The Future

Hoi folx,

a happy new year to all of you.

Now that 1.1 ist finally out, I am missing a kind of a TODO file.
Could someone please comment on the planned/thought of additions/enhancements
to squid?

Maybe I'll start the discussion with a wishlist :-)
Two things I have thought of for a long time but had no time to
hack them in yet:
1) make the ACL module a seperate process.
   Why? We are a ISP in Germany. We primarily provide the squid service
   to our customers. Unfortunately our class C networks are not
   contiguous, so we had a rather long ACL list. We noticed that this
   had caused some significant performance degredations (as squid has
   to check the ACL list on every connection it receives). I have played
   with the order of the ACLs and moved the most frequently used to the
   top of the list. This made things a bit faster. But finally we
   decided to ignore the "holes" in the list and open quasi class B
   nets. This reduced the list from more thn 100 entries to about 20 and
   made squid faster again.
   My idea was to make a seperate module like dnsserver and put all the
   ACL stuff there.

2) allow for separation of HTTP headers and content in the cache files
   and own names for the cache files.
   Why? I am also working in my spare time for a large free software
   archive (http://www.leo.org/pub/).
   Currently we provide all the files via FTP although navigation is
   possible in HTTP (and we plan to keep this unless HTTP supports
   something like a REGET as FTP does).
   In cooperation with the relocator module we think it would be a
   great benefit, if the files fetched through the squid cache could
   be also put in the FTP archives. This would make it possible for
   external users to access a software repository built by the (dynamic)
   squid cache. However this would make it necessary to strip off the
   HTTP headers and allow for a more intuitive naming of the files
   than squid does it now.
   I know that this is a real hard thing, as it has sideeffects on
   cache_size, ttls and nearly everything else but especially with
   powerful relocator and the current efforts of the UR* working groups
   I think it might really be worth a thought.

Thanks for listening

        \Maex

-- 
SpaceNet - Gesellschaft f.                          http://www.space.net/
innovative Netzwerktechnik mbH                        webmaster@space.net  
Muenchner Technologie Zentrum                      
Frankfurter Ring 193a                             Telefon: +49 89 3246830
D-80807 Muenchen                                      Fax: +49 89 32468351