On Mon, 30 Mar 2009 11:38:31 -0600, Alex Rousskov <rouss...@measurement-factory.com> wrote: > On 03/30/2009 03:16 AM, Pieter De Wit wrote: > >> I gave this some thought. Why don't we build a system close to >> sendmail's milter system. An API where by clients can plug in and offer >> services - one can be a traffic counter, traffic limiter (as what we >> proposing here) and maybe a URL block, a virus scanner etc. > > We already have such a plugin API for message- and content-related > tasks. It is called eCAP, and it has been mentioned on this thread. > > Compared to eCAP, traffic shaping and quotas are different in scope as > they work on multiple messages and often do not care about the messages > at all (just raw bytes traffic). So, we have a few options: > > 1) Use eCAP nearly "as is" for traffic shaping and quotas, even though > it is not a perfect fit for the task. > > 2) Significantly enhance eCAP to offer traffic shaping-specific hooks > (as a standard addition or as a Squid extension), even though it may > lead to eCAP API bloat. > > 3) Develop a different plugin API that specializes in aggregate traffic > management and is unrelated to eCAP, even though it may lead to > duplicating a lot of eCAP-related code. > > I am not sure, but I think option #2 is the worst. What do you think? > > Cheers, > > Alex.
Hey Alex and List, Sorry that I didn't read up on eCAP before starting this process, but I believe that it won't be on the TODO list if eCAP "does it right". What I saw in my mind is something like this : Client/Bandwidth limiting registers with squid ... squid get a request to download object x from site y by user z at ip a.b.c.d etc squid sends that request to the client (just "text" not the object) client replies "yes" or "no" - if yes the client needs to track how much data is left for that user etc. (Client here is the limiting software - couldn't think of a better name...coffee....) I feel this should be a persistent connection that is matched by an acl for speed etc. Now to the workings of this. I am leaning towards option 3. I am not sure how hard it is to maintain "two" API's. To be honest, I am not even sure how hard it is to maintain one API. I feel that this really only needs two or three commands, so is it really going to bloat the API ? Broken down - what is the most "this API" would need ? Cheers, Pieter > <snip - I am sure they can find the follow up in the archive :)>