[squid-dev] [RFC] The situation with helpers/

[Alex Rousskov]

On 01/04/2016 08:58 PM, Amos Jeffries wrote:
> The SBuf and CharacterSet patch auditing has brought up the questions of
> why helpers/ is separate from src/, built first, what cross-dependency
> there can be, and even why we are bundling C++ helpers to begin with.
> 
> So lets clarify it formally once and for all.
> 
> Q1: why is helpers/ built before src/ ?

A1: Primarily for historical and paranoia reasons.


> Q2: why is helpers/ separate from src/ ?

A2: Primarily for historical and paranoia reasons.


> should we shuffle them back to src/*/helpers/ directories on a
> per-component basis ?

Yes w.r.t. src/. There is no known good reason to enact artificial hard
barriers between parts of Squid code. All Squid code should be in src/.

Not sure whether the helpers/ subdirectory is [always] needed but that
is a separate question.


> * it does somewhat hinder anyone wanting to manually build a single
> helper. Though I have not heard of anyone doing so in many years.

The move does not preclude anyone from building a helper. The fact that
a few more things may be built along the way is a minor detail IMO.
Patches to improve dependency tracking (by migrating away from recursive
Makefiles??) are welcomed.


> * it does mean we should probably discard the goal of having the helpers
> be demo code examples for people to base their custom helpers on.

The location of the helper code is pretty much irrelevant for the above
goal. However, if we want to provide demo helpers that are easy to
understand and customize, then we probably should not use C++ to write
those demo helpers.

* If we want to provide the smallest set of default helpers for the
widest possible set of deployment environments, then internal
dependencies are preferred to the external ones and, hence, C++ is the
best language choice.

* If we want to provide default production-quality helpers for the most
demanding deployment environments, then internal dependencies are
irrelevant, and C++ is the best language choice. Please note that I do
not know whether it is wise to declare performance the primary goal,
given the performance deficiencies of the helper interface itself and
the current Squid Project resources.

Any open source helper can be examined, customized, and cloned, of
course. Our decision with regard to programming language and
dependencies may make it easier or more difficult, but not impossible.
It is a question of the primary optimization target: ease of
understanding/customizability versus supported platforms versus performance.


HTH,

Alex.