update elicitation mechanism to allow for elicitations outside of the…#792
update elicitation mechanism to allow for elicitations outside of the…#792
Conversation
|
@anna239 could you share a bit the behind the scenes conversations to understand the decision making around it? |
| pub session_id: Option<SessionId>, | ||
| /// Optional request ID if this elicitation is tied to a specific request. | ||
| #[serde(skip_serializing_if = "Option::is_none")] | ||
| pub request_id: Option<RequestId>, |
There was a problem hiding this comment.
Do we want to require one or the other? I can help turn this into an enum to express that you have to have one (and not non or both?)
|
@yordis it's clear that there are use-cases for other methods that this can be helpful. The idea is to have it either for a session or some other request, and then the client would need to have some way to express general elicitations, for the auth/configuration phases to be concrete |
Related to #376 (comment) @benbrandt that was a precise question in the RFD, and the idea was that such workflow didn't belong to the Elicitation per se, which it is fine, I do not have strong opinions, but overlapping concepts may arise. Documenting the decision making would be amazing, so we all have a trail history of the "why" behind it. Sometimes isn't obvious what the motivation is, so it helps to share the intent. |
|
Sure thing. before we merge this we would need to update the RFD which is where we'd capture that |
3 participants
… session scope