I’d like to propose two additional events available via the events API: LocalIndexUpdateTriggered and RemoteIndexUpdateTriggered.
I still don’t understand how st works, so pardon me if I talk nonsense, but I imagine that LocalIndexUpdateTriggered should be generated as soon as it’s clear to st that we are going to update the local index. At the same time this information should be sent to other devices so that they can generate RemoteIndexUpdateTriggered.
In terms of generated traffic this causes only a minuscule increase.
My direct reason for that is that this allows for a little bit more precise monitoring. For example, I think it’s established that “st type software” is used also in the following situation: I ssh to a remote host which runs st, I copy data to ./Sync on remote host, I wait for the data to be synced. Now if my local host gets RemoteIndexUpdateTriggered say 3 seconds before RemoteIndexUpdated then for example stiko can inform me about it 3 seconds earlier than now, saving me 3 seconds of wondering whether everything’s ok.
Imagine that: you log in to a remote host, you start copying something to ./Sync, and 0.1s after copying has finished your notification icon tells you syncing has started. Gives you really nice feeling in your tummy.
An indirect reason could be that this will at some future point also allow to speed things up for the syncthing application: if there are things which must be done after RemoteIndexUpdated is received, but which do not directly need seeing the remote index (like perhaps creating the local index?), then this can also be done 3 seconds earlier.
A proposition for a new REST function is unrelated to the above, but it’s also meant as a helper for stiko type application. When stiko starts it’s sometimes hard to know where we are in terms of st operation. For example, conceivably, we might be in the middle of syncing which goes very slowly, and no sensible events are generated for good couple of seconds or even more, and stiko just can’t correctly tell the user what is going on.
So it’s natural that stiko asks st about various things accesible via REST. But in the mean time maybe new events are generated? And so on. I’m sure one can deal with it with current means (although I don’t quite know how to really cover all corner cases). But it would be nice to have a REST call: just_tell_me_everything(), which would tell the config, connected hosts, all known information about connected hosts (like their most recent FolderCompletion), and so on, and the id number N such that all that information is current as of event N. Then stiko would also at its start know where we are, and that we should just start listening from event N+1.
This reminds me about the third issue: according to the docs, id is “A monotonically increasing integer”. Doesn’t it go to zero sometimes?