Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional maintainers + Vision #24

Closed
passcod opened this issue Jul 26, 2015 · 12 comments
Closed

Additional maintainers + Vision #24

passcod opened this issue Jul 26, 2015 · 12 comments

Comments

@passcod
Copy link
Member

passcod commented Jul 26, 2015

I'm going on a 5-week holiday soon, and will probably not be available to do much on this during that time. Even apart from that, I'm generally quite busy from work and my contributions to Notify have been reduced to merging changes and shaping discussions for a little while now.

I'm looking for maintainers to help with this. You'll get commit and crates.io access, a nice badge on your posts in issue threads, and eternal thanks.

My vision for Notify can be summarised thus:

  • A single library for file watching in Rust, à la fs.watch in node, Listen in Ruby, fsnotify in Go.
  • I'd love for it to be embeddable / usable in other languages. C is the obvious target here, but there has been some recent forays in Python-to-Rust-and-back, for example.
  • Since Single file support for inotify #22, Notify should be able to watch both directories and single files.
  • A single interface for file watching. Yes, different system interfaces have different options, and one may want to take advantage of some advanced feature of one, but not here. They can use a binding directly. Notify should remain the same across all platforms and implementations.
  • Abstract away as much as possible from the backends. See this comment on #22. Afaik, fanotify on Linux is the only backend that could provide recursive directory watches natively. Notify should allow fanotify to handle that, as it will do so far more efficiently than us, but it should also take care of recursive watching for the other backends.
  • A more advanced vision of the above is to compose backends if necessary. On Windows, the native call can only watch directories, not files. We could implement single file watching by watching the directory above and filtering events, or we could use the PollWatcher to watch that file. The behaviour could be chosen dynamically, e.g. a large amount of sibling files in that directory may generate a large amount of events, and in that case it would be preferable to switch to a PollWatcher.
  • Speaking of, the current PollWatcher is lacking terribly, see Polling: handle metadata and name changes #20.

Pinging those of the current contributors who aren't watching this repo: @blaenk @octplane @andelf @retep998 and I'll also post this on Reddit for visibility.

@passcod
Copy link
Member Author

passcod commented Jul 26, 2015

Note that my vision has been malleable in the past... these are not rules to follow:

More like guidelines

@nagisa
Copy link

nagisa commented Jul 26, 2015

I always had a similar project (and my own ideas about it) in mind, so if there’s nobody who steps up, I could.

@corbin-r
Copy link

I could definitely pitch in!
I'm going back to college 3rd of next month, but! That doesn't mean I can't pitch in now and even after I go back!

@retep998
Copy link

I guess I can maintain the Windows specific code. Maybe I should stop waiting for @maurizi and just finish my implementation and submit it.

@corbin-r
Copy link

I'm on a Macbook so I could maintain and patch up OS-X/Linux distro code.

@blaenk
Copy link
Contributor

blaenk commented Jul 27, 2015

I'll help out. And yeah, we're still sorely lacking a windows driver.

@passcod
Copy link
Member Author

passcod commented Jul 27, 2015

Awesome :) I'll add @blaenk and @retep998 for now.

@franleplant
Copy link

My two cents:

I'd like to make myself available as a junior maintainer if something as such exists.

I have access to Linux, Mac and Windows machines and I consider myself a Rust beginner, perhaps I could make myself useful in common tasks, improving the docs and so on and so for. Just let me know.
My goal is to learn and contribute.

Thanks!
Fran

@corbin-r
Copy link

I'm with @franleplant, I just started learning Rust like 2 weeks ago.

@passcod
Copy link
Member Author

passcod commented Jul 27, 2015

@franleplant @polyg0n The best thing to do in this case is to submit pull requests and participate in issues if you feel like you can be helpful :) Documentation and tests would be great contributions to start easily.

@franleplant
Copy link

@passcod great, thank you very much!

@corbin-r
Copy link

@passcod Not a problem! Can do 😄

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

No branches or pull requests

6 participants