Re: [RFC] helper API

On Sun, 19 Sep 2010 20:54:03 +0200, Henrik Nordström
<henrik_at_henriknordstrom.net> wrote:
> fre 2010-09-17 klockan 12:20 -0600 skrev Alex Rousskov:
>
>> If needed, the Framework can expose the descriptor or class for writing

>> responses but it will become more complex and rigid if we allow such
raw
>> access. I do not know whether it is needed. I am not a helper expert.
>
> It's not needed. But the API need to provide some kind of handle which
> abstracts the old/concurrent details ("channel").
>
>> I do not know much about auth and external ACL needs, but if they are
>> also hungry for more info, the same argument applies.
>
> auth is intentionally stripped down from providing more info.
>
> external acl by definition provides a lot of information, but only the
> specific information requested by the acl definition.
>
>> Again, compatibility with eCAP does _not_ imply that helpers become
>> embedded. It just leaves that possibility open in the future, without
>> rewriting all helpers again.
>
> url rewriting is a prime candidate to be replaced by eCAP I think.
>
> This said the main benefit of the current helper interface is it's
> simplicity and language independence. There is various helpers in C, C
> ++, perl, python, shell script, php and probably a number of other
> languages as well. I do not see C or C++ as the primary language for
> helper development, rather perl & python today. Many of the existing
> helpers would benefit from being rewritten in perl or python.
>
> I do not see it as a desirable goal to encourage others to write more
> helpers in C or C++. Generally better if they use a scripting language
> such as perl or python as it's much less risk doing something stupid,
> easier to maintain and easily integrates with pretty much whatever which
> is what helpers usually is about.

While I agree that scripting languages would be better to promote for
third-party helpers. Several of the existing ones (edirectory_userip for
example) are in C/C++ because they need speed and lower overheads than perl
can provide. If python can provide smaller binaries with less overhead that
would be a contender.

Amos
Received on Sun Sep 19 2010 - 22:07:52 MDT