Base API on futures-rs

[hannobraun]

The current API offers both synchronous and asynchronous operation, but it would be better to do that based on futures-rs. I've looked into it, but decided to hold off for the moment, until I had a chance to learn a bit more about futures-rs and experience it from a user's perspective (as opposed to that of a library author).

[arsalan86]

I'm working with futures-rs (and learning from it) on a personal project. I think implementing futures-rs would be really useful, and should be a target for 0.5. Do you have any thoughts/suggestions (or even existing code) about how to go about this?

[hannobraun]

I have some thoughts, but not many:

• There's existing code: tokio-inotify, which is a wrapper around an older version of inotify-rs.
• tokio-inotify implements Stream. The inotify-rs API has become more low-level since then, so I don't think this will work any longer, as inotify-rs no longer manages a heap-allocated buffer. I'm guessing that returning a future that returns an iterator from read_events would be the way to go.
• The point where I gave up was when decided what to do about Handle. You seem to need a Handle to do stuff with Tokio. We can probably just assume that a future-enabled API that uses inotify-rs already has a Handle, but what about end users that don't have one and don't know how to get one? There must be a way to support both use cases conveniently.

That's about it. I still don't have much experience with futures/Tokio. Some of my question might be easy to answer, but I think there will probably be undiscovered problems that I'm not aware of. When I looked into it, I gave up pretty quickly, as it wasn't a high priority at the time (I think it's very important long-term, though).

[hannobraun]

and should be a target for 0.5

I generally don't like setting such goals for versions, as I prefer to just release when there are enough useful changes. For example, I plan to take a closer look at issue #61 soon. Any improvements in that area, together with your pull request (#67), are already useful enough by themselves. If a futures-based API were ready at the same time, then fine, but if not, it can just go into another release later.

[mathstuf]

The point where I gave up was when decided what to do about Handle. You seem to need a Handle to do stuff with Tokio. We can probably just assume that a future-enabled API that uses inotify-rs already has a Handle

Yes, the code which creates the event loop holds a Handle it is used to ensure that the inotify-rs code runs in the appropriate event loop.

[Xudong-Huang]

I have a porting based on may, the interfaces are the same as before.

[mathstuf]

@Xudong-Huang Thanks, but that doesn't help me :) . I'd like to have events available as a Stream (or equivalent) in future-speak so that I can mesh it with other event sources, not that it's just backed by asynchronous code.

[hannobraun]

Thank you for the info, @mathstuf and @Xudong-Huang.

@mathstuf, I currently have no short-term plans to work on this. I'm currently waiting to see how the upcoming futures/tokio changes will shake out. I'm happy to assist with code review and answering questions, if you'd like to take a look at this yourself.

Alternatively, you can take a look at notify. I believe there's ongoing work on the next version, which involves futures. See this issue for more info.