>>> Tsantilas Christos <[EMAIL PROTECTED]> 02/27/07 6:27 AM >>> Hi Adrian,
Adrian Chadd wrote: agree ..... > Yes, I'd like to do all of what you've suggested above but I'm going to do it by > junking most of the client-side request/reply handling routines and replacing them > with stuff written from the ground up to use a sane API. Buffers won't be copied; > stuff will be parsed once and parsed quickly; the whole of the URL rewrite/XFF/ > Acceleration/ACL lookups/etc will be implemented as a state engine with events > rather than callback-driven like it is today. Its also doable in a -lot- less code > than is traversed today. > > I believe the only way we're going to get long-term benefits out of any improvement > work is to pick some medium term goals (mostly structured around knowing what > we'd like the code to look and picking incremental API and code decisions which > take us down that path) and working on them piece by piece. > Ok Adrian, I am watching the mailing list and I know what you want to do. I believe too that some parts of squid needs redesign, if the project wants to survive. Squid is an old and huge project. And you must continue your work because you want a fast http proxy, with cleaner code and better api's . In the other hand I need a proxy with an icap client because I spent time (and continue spending) to an icap related project. Squid3 has a good icap client. The first problem someones can see in squid3 is that there are some parts derived from c-code, which are not (fully) converted to real c++ code. The second is a feeling that some parts of code are half-completed. I am thinking that maybe it is good practice for someone to start fixing this things first.... An alternate for me is to try fix the bugs and rewrite some of the icap-related parts of the squid26-icap branch. I don't know .... Let me second this. When you start asking questions about squid3 and its stability, you get anything from "it's stable" to "not for prime time" and when you ask questions about using it in a production environment, most shy away from that. but I need ICAP support and proposals like this, although valid, scare me a little. (rewriting the client side code from scratch, not putting icap in 2.6) I don't have the time to go digging on 2.6 to make icap work better, so if you have some spare cycles it would be greatly appreciated. _J Regards, Christos