Expose a way to observe the state of the network

[mpickering]

In my IDE, when an event fires, it would be desirable to be able to report to the user how long it will be until the event has finished propagating through the network. As this process can involve running arbritary IO commands, it can certainly take some time to happen.

Therefore I think it would be good if there was a hook which reported information about the state of the network. For example, 10 events already processed, 100 events still to process or some other sensible progress metric.

I had a look about how to implement this but didn't get very far. Perhaps modifying Reflex.Spide.Internal.run would be one way to go.

[cgibbard]

Hmm... it's unusual to have single frames that take so long to process. While I haven't had the chance to look at how your IDE work is structured in more detail, I would expect that most IO that is triggered by a Reflex system to occur via performEvent or performEventAsync. As such, if you want information about when those are starting and ending, you can compare the firings of the event going into the performEvent/Async with the ones that have come out. If the IO is taking long enough that you want progress information in the first place, it's probably more appropriate to be using performEventAsync so that you can fork a thread inside and not make the rest of the system unresponsive.

If you do that, and take care to only execute the firing continuation that performEventAsync gives you once, you should be able to simply count the occurrences of the input and output events and compare them to know how many commands are in-flight.

[mpickering]

You are right that the IO is happening in performEvent, but performEventAsync doesn't work for me because of #404.

One issue I see with performEvent is that in a push based system it is hard to predict how much more stuff there will be to do. It seems your suggestion here is to increase the total counter at the start of each performEvent and decrease it when the event returns. It could still be good to just report each call to perform event to the user anyway without any notion of percentage completion.