Re: [RFC] helper API

On 17/09/10 10:18, Alex Rousskov wrote:
> 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...

Yes. Framework sounds more like what I'm asking about.

You mean provide a call to fetch a socket needed to send/receive from
Squid. Hiding the current std* ones behind the call until some future
re-work finds a need to change it?

>
>> * 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?

At the moment its just this:
   #define SEND_OK(x) fprintf(stdout,"OK %s\n", (x))

helpers may use the wrapper for convenience and easier to read code.
I've converted several of the simple helpers over already. But they are
still free to use the direct socket/pipe feedback if they need/want.

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

We are on the border. The helpers are C code built with g++ now. Future
ones could be pure C++.

>
>> * 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 :-).
>

Definition (as per status-quo):
  A third-party program for use by auth, external ACL,
url/store/location rewrite, and daemon logging. One which is started by
Squid automatically and processes requests received from Squid.

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

Thanks

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.8
   Beta testers wanted for 3.2.0.2