On May 22, 2013, at 15:21 , Alex Rousskov wrote:
>> Well, since the best documentation is code, I started with the
>> supplied helpers.
>
> And you can still use Squid helpers as API "documentation", of course.
> It is conceptually wrong that some distributed-with-Squid helpers use
> Squid libraries which are not meant to be used by external programs, but
> it is probably too much work to maintain those helpers separately...
>
>> Also, since many of the parameters that can be passed are
>> URL-encoded, I thought it logical to use the same routines in
>> libmiscencoding to decode them, as the supplied helpers do.
>
> A stand-alone helper can use a 3rd-party library designed specifically
> to offer URL decoding and manipulation. Most will be smaller, easier to
> integrate with, and may even offer functionality that is better than
> Squid's libmiscencoding.
Perhaps. I just thought using the same code seemed safest.
> I do not think reimplementation and encoding change tracking is
> required. As for other Squid changes, you are more likely to suffer from
> them when you link with Squid than when you do not. After all, all
> helper APIs are meant to use simple syntax with standard encodings, and
> standard encodings should not change often.
Understood. I've found that curl offers unencoding routine(s), and since
we have curl/libcurl installed, it's an easy thing to build against. I'm using
that now for the one helper I've converted out of the "build from within squid"
configuration.
> You may also consider writing in a different language. Most new helpers
> are not meant to be performance-sensitive (there is eCAP for those who
> care about performance these days) so using a high-level scripting
> language may be an overall better approach than using C++.
Perhaps. But, you're talking to someone who chose to write a C log_daemon
helper to write to a MySQL database. I wanted to log many more things than
the included DB helper, and if I was going to change it anyway, I'd much rather
not have a script, be-it perl or otherwise, running long-term in a production
environment. But, that's just me. I'm an old-school programmer. (And, I was
worried a little about performance, but it was more the principal.)
Especially given how frequently the ACL will be called (for every request),
I am very worried about performance. (Note that I'm not familiar with eCAP,
so I may be missing something.)
- Chris
