Initial work on dashboard.

[isaacabraham]

Do not merge this PR yet - please review and provide some suggestions on how this can be improved (or if it's even worth investing any more time in this).

Use it with e.g. Dashboard.OpenDashboard cluster which will open a simple WinForms form created by FSharp.Charting with live updates for Active Work Items, CPU and Network throughput.

[eiriktsarpalis]

I like it. It's a good companion panel when doing work from fsi.

One issue I came across is that "Dashboard.fsx" loads either AzureCluster.fsx or ThespianCluster.fsx at its beginning. I didn't notice this at first which made me unwittingly switch to a thespian cluster while I was using azure. I think that it should not reference either of the two scripts and should only depend on MBrace.Runtime.Core.dll in order to avoid such accidents.

Another issue is that the active work items pie chart was difficult to read at times.

[dsyme]

A few things

• Can we put this under "examples" or "lib" please?
• It's really very important for MBrace to avoid dependencies on things that are definitely Windows-only technologies. It's very clear that MBrace has to have a very good experience on Linux in the long term and that this shouldn't be a second-class citizen. Every time we do anything pinning MBrace to Windows, we create more and more trouble for ourselves in the future. So please, could we change this to use a web browser as the dashboard? Or build this on Eto.Forms? That is structurally so much better even if painful to arrange in the first place. If we don't do that, then we'll just end up deleting this sample at some point in the future in a later effort to go cross-platform.

[isaacabraham]

Frankly I don't have a problem with rework later on if it means in the immediate term we are further along anyway, but yes, x-plat is something we should think about.

FSharp.Charting does have a non-Windows version, but AFAIK there is no "one size fits all" package. We can make this browser based, but either (a) needs us to then bring in something like funscript or similar to do the client/server communication. Or (b) need to add an HTTP endpoint to MBrace clusters that expose the metrics data so that you can query the data client side.

As I said in the PR description - I did this more just to experiment and get feedback, plus it is useful when demoing MBrace instead of just sitting around waiting for a query to complete.

[eiriktsarpalis]

I wouldn't mind having this as an interim implementation. It would be a great companion for next week's tutorial too.

[isaacabraham]

I've made some final changes - I suggest we merge this in and then open up a separate issue in MBrace.Core to discuss the x-plat story. My understanding is that there's more than just a charting library required in order to enable this.

[dsyme]

@isaacabraham It's true there's more than a charting library required. But I'm keen to make sure we don't build up technical debt here, and that we don't convey the impression that this is a windows-only technology even in the starter kit.

Also, we'll be doing all of the F# data science initiatives (FsLab etc.) a favour if we dogfood the more cross-platform stuff there (e.g. google charts etc.), and help build out the web visualization for F# - including interactively updating displays. I don't think we need any dependency on FunScript of WebSharper at this point as we can just deliver HTML to a browser. Tomas can help here too.

[isaacabraham]

I'm pretty sure we can't just deliver HTML to a browser as these are live charts updated every n milliseconds - there needs to either be some client coding or something else. Happy to be proved wrong though as I really like XPlot!

[dsyme]

Right, not "just". And not just plain HTML. But HTML5 can handle the updates.

What I'm saying is that we can't afford to do OS-specific client tooling in the long run, no matter how nice client apps might be (unless it's built with cross-plat UI components like Eto.Forms, OxyPlot and Xamarin.Forms). We just have to avoid it and the technical debt associated with it. And we have to take MBrace onto Linux, and better sooner rather than later. (The first thing should be to get Linux on the cluster of course)

[eiriktsarpalis]

@dsyme Agreed. Let's try to keep this sample dead-simple, without taking any effort to implement additional features until we replace it with a truly cross-platform solution.

[isaacabraham]

@dsyme @eiriktsarpalis agree :-)