On 09/16/2010 02:46 AM, Amos Jeffries wrote:
After the helper C++ build migration we have a partial API for the
helper tools. Some of them even make use of the #defined macros.
I managed to bungle and put the old-style debug() definition for helpers
into the libcompat. It's now clear that this would be better suited in
the API for helpers and non-squid tools.
What I'm looking at right now for the helpers is:
* some wrapper for main() that calls out to user functions for handling
a line received and processing command line options.
> * some definition of the user functions required to do the above.
If I understand what a helper is, and helper API should not wrap main or
standardize command line options processing. Main should be left for the
helper to control and there are probably enough libraries out there for
options parsing.
We can standardize a subset of common command line options, of course.
If you want to offer a helper development framework with such things as
built-in I/O and reconfiguration handling, then things change. You may
indeed take main() ownership and just leave some places for users to
plug their code into. I would not classify that as API though because it
restricts the implementation way beyond a common API needs.
And if we are doing a framework, we can remove current limitations
related to handling helper's standard input/output. We can just use
sockets...
* some macros (as now) for performing OK/ERR etc feedback to squid.
These take a char* parameter for additional key-pairs or messages.
By "performing feedback", do you mean actually writing bytes to the
stdout stream? Or just formatting the output for the helper to write. Do
you want to support helpers that want to manage I/O on their own? Do you
want to support embedded low-overhead helpers, eCAP-style?
* the debug() call doing printf-style output as now but with automatic
prefixing of helper name and PID (matching the kidN for cache.log)
Printf() is far from ideal for C++ helpers. I do not know whether we
have or expect any though.
* standardizing the -d (debug on) and -h (help) parameters for all
helpers compiled.
Does anyone have any advice about good ways to make a formal public API
that the existing bundled helpers, and potentially third-parties could
use when building C/C++ helpers for Squid?
ie things that must be one for versioning alterations over time.
I would start with defining what a helper is, and what you want to
provide helper authors/code with: A simple API/library their programs
would use, a framework where they can just plugin their custom stuff and
that would do I/O and process management for them, eCAP-like integration
API for embedded helpers, something else? You probably know all these
answers, but they are not obvious to some of us :-).
Can we do it without a built library? ie only inlines, templates and
macros?
Yes, most likely, especially if you just want a simple API. Boost
manages to do a lot with just headers. Doing a good API for both C and
C++ helpers may be impossible though. You will probably need to focus on
one and then optionally provide a wrapper for another.
HTH,
Alex.
