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!
I am the current maintainer of the project at Stack Overflow. Thanks for your feedback. In general, we are ok with any pull requests that add new functionality while maintaining what is working right now, and I will be happy to facilitate including these changes in new nuget releases.
OWIN-support: this is not something that we have planned, but it could be included if you want to put the work in
Policy-based ability to turn data collection on and off: you can control whether or not MP runs on a request-by-request basis by calling MiniProfiler.Start(); in Application_BeginRequest(). Likewise, you can call MiniProfiler.Stop() at any time to stop profiling if you no longer need it.
MP works for Web API right now. I have it running in one of our internal apps where Web API and MVC run in the same app, and MP profiles Web API requests and returns results to the UI without issue. Have you had difficulties with this?
REST call support - what are you interested in?
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.
MP serves our needs at Stack Overflow right now, so it has been some time since we have done any active development on it for new features. That said, new features can be included by PR as long as they don’t mess cause regression issues that would affect its current usage patterns (unless there was a good cause for it and we got internal approval here from the different teams that use it). But please feel free to open up GH issues to discuss any potential ideas that you have.
We would definitely be interested in OWIN support. Most of our stuff is headed to OWIN and ASP.NET 5. I’ll have to do some research to see if I can better quantify it and get some issues filed so we can work on PRs.
I see what you’re saying on the policy-based security thing. That could probably be a custom piece. If we come up with something that looks like it could be interesting or generally useful we could always offer it up in a PR.
Something in that which may be breaking is that there are ties to System.Web, System.Data, and other non-portable things from the core MiniProfiler package. None of that will work in ASP.NET 5 and/or OWIN (self) hosting. Making the common bits portable across the different platforms would be really valuable, but I can see that breaking the assembly up that way - such that only core data structures are in the core and everything platform-specific including even the basic SQL profiling and legacy ASP.NET profiling support would be in separate assemblies - could be a fairly large shift.
The Web API challenges we’re looking at are for things like OWIN and self-hosting. There’s no HttpContext so having a mechanism to store context in HttpRequestMessage or OwinContext rather than HttpContext is what we’d be looking for. Probably the OWIN middleware solution would be able to address that, standardizing everything on OwinContext. I could see that fairly easily being a separate package.
I also didn’t see for REST calls where there was any hook into HttpClient like there is for WCF calls such that you can profile downstream REST calls from one app to another. Maybe I missed that. That’s definitely something we’d want.
Anyway, thanks again for getting back to me. I’ll talk to my team and see how we want to proceed. If you see anything in here so far that sounds like it may not work out, do let me know.