Hey Nishant, Responding to your idea and the whole concept of the helper and also comparing to GoLang binaries. About the software design to run on-top of embedded hardware and a GoLang binary: A GoLang helper can be compiled to almost any modern embedded device(else them mips based) Also its more efficient then any software you will write with perl. The only "limit" is CPU comparability and Binary size vs device free space.(in any case a perl helper would use more then a GoLang one). The idea of writing a software that will implement concurrency in perl or python is nice and noble but I believe that probably for small embedded devices you won't need a "robust" helper that supports concurrency or any other more complex solutions. I believe that you should aim for the more standard hardware devices which squid can be built on-top such as: - x86 - x86_64 - arm64 - arm5 - arm8 The above will benefit from a good and robust helper which supports concurrency. Now that it's clear that your socket can handle more then only one request I will write a helper in GoLang that works with: - concurrency - better connection handling(being able to handle responses whenever they received) I already wrote most of the code so I believe it's a matter of days for the helper to be ready. Would I be able to receive some testing api key\token once the helper will be ready? Thanks, Eliezer ---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: eliezer@xxxxxxxxxxxx -----Original Message----- From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Nishant Sharma Sent: Saturday, June 17, 2017 21:30 To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Introducing Charcoal - Centralised URL Filter for squid On 17 June 2017 11:17:38 PM IST, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: >That would mean making Squid aware of the internal workings of the >helper. Namely that it uses connections to a specific server, port and >which transport. One of the major points of flexibility with helpers is > >that this kind of thing is kept completely separate from Squid. Re-reading my mail made me realise that it conveyed that helper architecture of squid be modified, instead I wanted to say that we can modify the architecture of our helper, where it internally manages its own children which may speed-up the URL rewrite process. >The URL-rewrite API being used by charcoal has the purpose of altering >the URI which Squid fetches content for a client from. Doing access >control through it instead of the access control API (external ACL >helper) is kind of borked from the start. I agree, external ACL helper will also allow to have access to additional information like user-agent, reply content-type etc. to have more granular control. Regards, Nishant -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
