Embeddable Server Composition

[leseb]

Problem

Praxis supports custom filter registries, but downstream distributions
that need pipeline extensions or activation must copy generic server,
reload, watcher, and validation code.

This makes lifecycle ownership unclear and causes generic fixes, such
as reloadable subrequest policy, to be implemented downstream.

Proposal

Add a supported server composition boundary.

Downstream distributions provide their filter registry, pipeline
extensions, and activators. Praxis retains ownership of resolution,
activation, publication, reload, listeners, health checks, validation,
dump, and server-managed runtime policy.

This should integrate with Async Pipeline Activation,
preserve existing entry points, and remain narrower than a general
plugin framework.

Does this ownership boundary make sense?

Value Proposition

Improve the AI repo by removing duplicated server, reload, watcher, and validation code and keeping generic lifecycle behavior in Praxis.

[Artemon-line]

+1 on this. Having Praxis core own server composition and the reload lifecycle makes a lot of sense.

We ran into this exact boundary issue on praxis-proxy/ai#639 when trying to make outbound AI callouts respect reloaded body_limits.max_response_bytes. We initially worked around it downstream with an ArcSwap handle, but it made it obvious that subrequest policy and reload lifecycle belong in Praxis core.

If core manages the CalloutClient policy reload (via ArcSwap), downstream filters using the shared client will automatically pick up updated response limits on reload without needing custom factory re-registration or duplicated watcher code.

Happy to help implement the CalloutClient reload plumbing in Praxis core for this!

[leseb]

Strikes again in praxis-proxy/ai#830

[shaneutt]

I understand the problem and it makes sense. Let's get a proposal in to establish the What/Why first, and then we can start working ourselves towards the architectural changes.

[leseb]

praxis-proxy/enhancements#10