-
Notifications
You must be signed in to change notification settings - Fork 7
Open
Milestone
Description
Splitting up the callback into a client & server variant makes sense as most users of this crate are either or, not both. This would also allow a better typing of the Callbacks as e.g. client callbacks don't need to implement validate, while server callbacks have to.
This would also allow a protocol implementation to require Callbacks with a given specialization. A server callback could thus statically type the additional data provided by SessionData and the type required for validate:
pub trait Specialization {
/// Additional data provided by the protocol implementation in callbacks.
type SessionData;
/// Validation type returned on successful authentication
type Validation;
/// Error type returned specifically on failed authentication, can indicate type of failure.
type ValidationError;
}
impl<S: Specialization> SessionData<S> {
[...]
fn protocol_session_data(&self) -> &S::SessionData { ... }
[...]
}
pub trait ServerCallback<Specialization> {
fn callback(&self,
session_data: &SessionData<Specialization::SessionData>,
context: &Context,
request: &mut Request
) -> Result<(), SessionError>;
fn validate(&self,
session_data: &SessionData<Specialization>,
context: &Context
) -> Result<Specialization::Validation, ValidationError<Specialization::ValidationError>>;
}Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels