Cleanup: Move AsyncEngine to libbase.la

[yadij]

No logic changes.

[kinkie]

LGTM

[rousskov]

I do not think AsyncEngine belongs to libbase. It is small but not a "fundamental commonly-used piece of code" that libbase is meant for. Let's not move AsyncEngine.h for now.

I support removing the evidently unnecessary src/AsyncEngine.cc.

N.B. AsyncEngine is not closely related to AsyncCall and related classes that currently reside in libbase. And even those classes may not really belong to libbase. Moving them (and AsyncEngine?) into a new dedicated libasync or similar library may be a good idea, as was suspected from the very libbase beginning (commit 5bd7a21) when we did not have as many asynchronous calls or as much experience with them.

[yadij]

I do not think AsyncEngine belongs to libbase. It is small but not a "fundamental commonly-used piece of code" that libbase is meant for. Let's not move AsyncEngine.h for now.

Correct reference for src/base/ content scope https://wiki.squid-cache.org/Features/SourceLayout. This file falls under the "has nowhere else to go". The existence of a "core" library was vetoed over a decade ago.

I support removing the evidently unnecessary src/AsyncEngine.cc.

N.B. AsyncEngine is not closely related to AsyncCall and related classes that currently reside in libbase.

Indeed. Nothing in libbase has any implicit relationship with anything else there.

[rousskov]

I do not think AsyncEngine belongs to libbase. It is small but not a "fundamental commonly-used piece of code" that libbase is meant for. Let's not move AsyncEngine.h for now.

Correct reference for src/base/ content scope https://wiki.squid-cache.org/Features/SourceLayout.

I disagree because SourceLayout page is a collection of (often unvetted) opinions that do not necessarily represent Project consensus.

This file falls under the "has nowhere else to go".

libbase is not a collection of things that have nowhere else to go. Even SourceLayout, with all its problems, does not make this mistake in defining libbase scope!

[rousskov]

Nothing in libbase has any implicit relationship with anything else there.

Some libbase elements are related (implicitly or explicitly). For example, eight Async*.h files are related to each other and to JobWait classes (also in libbase). There are other related things in libbase as well. However, these existing relationships are not relevant to the discussion about AsyncEngine. I only mentioned Async* classes in this context because they start with the same word as AsyncEngine which may lead to an (incorrect) conclusion that the two concepts are closely related and, hence, may belong to the same library. I am glad we agree that there is no such relationship.

[kinkie]

In the interest of moving this forward, how about setting up a src/events subfolder (and related libevents library) async look and events related code? @yadij @rousskov

[rousskov]

how about setting up a src/events subfolder (and related libevents library) async look and events related code?

Not sure what you meant by "async look".

If we want to group async calls- and async job-related code (currently mostly in src/base/) and events code (currently in src/) together, then I would recommend moving all that code into src/async/ rather than into src/events/: There is a lot more code/APIs to async calls/jobs than there is to events (and the events support itself is increasingly built on top of async calls)...

If we want to group just events-related code (currently in src/) together, then moving into src/events/ is fine. I am not sure there is enough events-related code (without async calls/jobs code) to designate a whole directory/library for it, but I would not be violently opposed to such a move if others are sure it is a good idea.