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.
Regards
Henrik
Received on Sun Sep 19 2010 - 18:54:08 MDT
This archive was generated by hypermail 2.2.0 : Mon Sep 20 2010 - 12:00:06 MDT