Polish profile-based endpoint stack#993
Conversation
This change renames `endpoint_override` to be `profile_endpoint`: "override" implies some behavior is being superceded, but in this case we're simply getting endpoint metadata in place of logical/concrete metadata.
| N: svc::NewService<(Option<profiles::Receiver>, T), Service = NSvc> + Clone, | ||
| NSvc: svc::Service<Req, Error = Error>, | ||
| NSvc::Future: Send, | ||
| E: svc::NewService<ProfileEndpoint, Service = ESvc> + Clone, | ||
| ESvc: svc::Service<Req, Response = NSvc::Response, Error = Error>, | ||
| ESvc::Future: Send, |
There was a problem hiding this comment.
FWIW, I didn't use separate type parameters for the service types because I noticed that sometimes push_xxx methods' target types can't be inferred, and reducing the number of type params means fewer _, _, _,s have to be written out at the callsite. This is absolutely not a big deal, so I'm happy to use this style if we prefer it — the where clause certainly looks nicer.
| impl svc::NewService< | ||
| (Option<profiles::Receiver>, T), | ||
| Service = OrOverride<E::Service, O::Service>, | ||
| Service = svc::stack::ResultService<svc::Either<NSvc, ESvc>>, |
There was a problem hiding this comment.
unrelated thought: might be nice to export a Switch type alias for ResultService<Either<A, B>> in svc, which is a bit more concise than writing out the whole type but doesn't require each stack layer to define a custom alias...not a big deal.
| pub fn push_endpoint_override<T, O, R>( | ||
| /// endpoint, and forwards directly to that endpoint (bypassing the current | ||
| /// stack) if one exists. | ||
| pub fn push_profile_endpoint<T, E, ESvc, NSvc, Req>( |
There was a problem hiding this comment.
👍 the "override" terminology was just my first thought when trying to describe this — it's probably not necessary.
I do think it might be nice to have a consistent language for layer functions that introduce a "branch", like this one and push_unwrap_logical, like or_profile_endpoint or something? but we can do that later.
There was a problem hiding this comment.
I think the "override" language might also show up in a test someplace — but I can fix that.
2 participants
This change renames
endpoint_overrideto beprofile_endpoint:"override" implies some behavior is being superceded, but in this case
we're simply getting endpoint metadata in place of logical/concrete
metadata.