Skip to content

Remove Serde trait bounds from EventSource and QuerySource#164

Closed
maciekglowka wants to merge 3 commits intomainfrom
fix/remove-event-source-serde-bounds
Closed

Remove Serde trait bounds from EventSource and QuerySource#164
maciekglowka wants to merge 3 commits intomainfrom
fix/remove-event-source-serde-bounds

Conversation

@maciekglowka
Copy link
Copy Markdown
Contributor

No description provided.

@maciekglowka maciekglowka requested a review from sbarral February 23, 2026 12:57
}
}

impl<T: Serialize + DeserializeOwned + Clone + Send + 'static> EventSource<T> {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, so it looks like we just moved the problem somewhere else :-/

I thought we would be able to get rid of the serialize bounds for register at least and that they would only remain for bind.
But this bound is required because the events are possibly schedulable...

Maybe it would be possible to remove the bounds on register but make sure that the bounds remains on the various schedule methods? But since Rust does not have specialization, I am not sure this approach is at all possible, because the scheduler registry would need to somehow ensure at run time that T is indeed serializable...

If it can't be solved, then I'd leave things as they are since this does not seem to make anything possible that wasn't before.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, sorry. I must have misunderstood the use of the non-serializable events. Indeed we made hard bound on the scheduler registry (to be able to serialize the entire queue). I will look deeper into it.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I didn't realize that this wouldn't be possible either, sorry for directing you to a dead end...

@maciekglowka maciekglowka marked this pull request as draft February 24, 2026 13:16
@sbarral
Copy link
Copy Markdown
Member

sbarral commented Mar 12, 2026

@maciekglowka Should we close this PR or is there any way forward?

@maciekglowka
Copy link
Copy Markdown
Contributor Author

If I remember correctly we have discussed to drop it as we didn't see a worthy solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants