impl futures::Stream<Event> for Subscriber

[vi]

For some reason, sled::Subscriber implements Iterator and Future - a strange combination.

Instead of Future, futures::Stream would seem to be a more reasonable choice. How do I keep watching on more events asynchronously otherwise?

Use Case:

Watching multiple operations happening to a Sled database (like with Iterator impl), but asynchronously.

Proposed Change:

impl futures::Stream for Subscriber {
    type Item = Event;
    ....
}

Who Benefits From The Change(s)?

Async Sled users.

Alternative Approaches

• Spawning blocking task to reach the Iterator impl
• Repeat watch_prefix after each received event. Assign sequence number to each entry in the database and explicitly retrieve entries that were added to the database while we were not "on the watch".

[asonix]

As noted in the documentation, you can use

while let Some(item) = (&mut subscriber).await {
}

But you're right that a .next() method or similar would be more intuitive

[vi]

Typically resolved Futures should not be polled again:

Once a future has finished, clients should not poll it again.

Relying on reusing Future after non-Pending poll is like relying on Iterator becoming live again after already returning None once. Even if it works, it does not play nice with various combinators and hinders understanding the code.

futures::Stream is a canonical "multi-use Future".

[busyboredom]

This feature would also be very nice for Actix users. I had a hell of a time trying to use a Subscriber as a second stream for an actix websocket (I ended up just giving in and polling instead).

[vi]

@busyboredom , I expect that one can workaround it with a manual Stream implementation where poll_next delegates to Sled subscriber's poll.

[tv42]

This sounds like a duplicate of #1311

The reworking of the idea to a sink sounds nice to me.