We want to start with what could be basic tracking of directories to find files, before optimizing for specific APIs in linux and OSX which allow more efficient file monitoring.
There's also a need to decide whether we want to use events (i.e. gproc pub/sub ) on all changes as a common interface, and let the storage be separate from these, or whether we want to create a reliable in-memory representation of tracked files.
In all likelihood, both are going to be needed: the events as an interface, and the "storage" as the current state representation that allows diffing (has a file changed or is it the same change we wanted to apply after a sync that got confirmed)
This should be done progressively:
[x] a basic interval-based poller that should be portable albeit inefficient
[ ] optionally use the linux inotify functions
[ ] optionally use OSX fswatch functionality on OSX
[x] allow a forced full re-scan (to build a base state from which changes are detected)
[x] allow all of these to be used interchangeably by plugging them in gproc properties for events
ferd
commented
5 years ago
We want to start with what could be basic tracking of directories to find files, before optimizing for specific APIs in linux and OSX which allow more efficient file monitoring.
There's also a need to decide whether we want to use events (i.e. gproc pub/sub ) on all changes as a common interface, and let the storage be separate from these, or whether we want to create a reliable in-memory representation of tracked files.
In all likelihood, both are going to be needed: the events as an interface, and the "storage" as the current state representation that allows diffing (has a file changed or is it the same change we wanted to apply after a sync that got confirmed)
This should be done progressively:
inotifyfunctionsfswatchfunctionality on OSXgprocproperties for eventsTests should be written for each of these.