On a project I’m working on right now we’re looking at a Glimpse or MiniProfiler sort of solution to help us get some information about what’s going on inside from a client perspective. I like MiniProfiler because it does a good job of keeping it simple and separates the display of the information from the data collection, which is pretty cool. We’ll probably end up with MiniProfiler.
There are some things I noticed aren’t there at the moment and we’d probably end up writing them.
- Support for OWIN-based applications. This is two parts - one for data collection (starting a profiling session as OWIN middleware in an OWIN-pipeline-based app) and one for display of data (serving the endpoint with the profiler UI as a middleware specific route)
- Policy-based ability to turn data collection on and off. Generally we probably won’t want data collection running for every request. I didn’t see where you could turn it on just for a specific request/user - it seemed pretty global, either on or off.
- Web API support. Along with OWIN support, the ability to track Web API requests, not just MVC requests.
- REST call support. Timings for calls from HttpClient.
That’s just stuff off the top of my head.
Where I’m going with this is that I haven’t seen a ton of movement in the MiniProfiler space and I’m trying to determine if it’d be better to fork or contribute. I’d love to contribute, but I can imagine that to get some of these things working there may be some things that need to change in the .NET implementations, like some of the ties to HttpContext.Current and so forth. Without doing the work, I can’t say it wouldn’t be non-trivial.
Any ideas on that? Whether it’d be better to fork or contribute back? If contribute back, how responsive would the maintainers be to discussions on changes? How receptive to potentially large changes would they be?
Again, nothing’s set in stone and I don’t know that we’d actually need to make any large or breaking changes, I’m just seeing what’s up. Thanks!