Re: Recommended method for building your own helpers?

On 05/22/2013 12:46 PM, Chris Ross wrote:
>>> But, I was wondering if there is another better/easier
>>> method to build helpers _outside_ of the squid source tree.

>> Yes: Ignore Squid sources and treat your helper as a stand-alone code.

>> Squid currently does not have headers and libraries reusable by external
>> code. I am curious what Squid headers and libraries you need to write a
>> good helper?

> 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.

> If I make it completely external, I would have to implement the
> rfc1738 decoding code, and then make sure to modify it if squid's
> ever changes. So, that's why I wanted to use squid's code.

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.

> I will try to extract the pieces I need and build externally. But,
> at least the rfc1738_unescape will need to be found somewhere.

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++.

HTH,

Alex.
Received on Wed May 22 2013 - 19:22:06 MDT