Open drcaramelsyrup opened 2 months ago
cc @jamesmunns
Thanks @drcaramelsyrup!
I think there's a couple main things to discuss at some point:
pingora
more clear (and maybe agreeing on where to draw the lines?)pingora
more "friendly" to different frontendsWRT 1 + 2: this would be things like removing configuration handling, and maybe things like signal handlers from pingora
itself, and instead lean on library APIs and methods that can be used to trigger those actions or provide config.
I'm happy to keep giving feedback as I go, or have a chat/call sometime.
WRT 3: I think once we get on the same page, it'd be good to just write it down in the docs, and link it in both repos. No need for crazy formalism :)
It'd be nice to have clearer guidelines that indicate the division of responsibilities between
river
(a pingora "frontend" that compiles into an actual binary) andpingora
(the core framework). We've been directing folks' issues toriver
when it makes sense.Some classes of features such as no/low-code configuration are already set to belong in
river
rather thanpingora
, but other cases may be less clear. For example, some features like Kubernetes ingress implementations per https://github.com/cloudflare/pingora/issues/41 are almost certainly destined forriver
and not corepingora
, but theriver
implementation may generate a feature request forpingora
; the exact division of code might not be clear until design time.This is a tracking and discussion issue for what those clearer guidelines should be and where to describe them. The ideal outcome is that we minimize confusion and issue redirection between the two projects.