Asynchronous Pluggable Protocols
Asynchronous Pluggable Protocols–that’s a mouthful. I came across this last night as I was doing some research on the Windows Forms WebBrowser control. First let me explain my motivation.
I have a situation at work where we’re using the WebBrowser control to window in our own company website because we never had the time to build a native Windows Forms application. The application we wrote allows our internal users a chance to review the data submitted by users on the website. Our internal analysts are presented with a window showing the web page with the user’s entered data and some additional data in the native application to help them in their analyses. This mixing of native UI and web UI has worked fine for a while, but doing that has had some drawbacks. For one, there is resource contention between the native UI which gathers additional data for the analysts to use and the website we’re windowing in. Both share the same database resources. That also introduces some concurrency issues–again because it’s like two entirely separate processes are reading and writing to the same place (one is the native application itself and the other is the website windowed in).
Some other less concerning, but still annoying drawbacks, are that we’re taking a performance hit. Having to window in a website that makes database calls through a DMZ and remoting/webservices to a database that we have direct internal access to in the native application is silly to say the least.
So why haven’t we written a native UI? Aside from the above mentioned lack of time, the web pages that we’re windowing-in are very complex data entry forms with as many as 700 input elements. Replicating and maintaining these as both web forms and Windows forms would be a maintenance headache.
I’ve floated the idea of building a UI framework that could render our data entry forms as both HTML and as Windows controls. That’s easier said than done though. They are very different beasts and usually when you build a UI framework that targets multiple platforms, one of those platforms suffers. In this case, our forms don’t translate very well to a Windows UI. Have you every tried to put 700 text boxes on a form before? It’s not pretty.
Another option I’ve considered is to continue to use the WebBrowser control, but instead of windowing in our website, we could window in some HTML pages created in memory. This would look/behave similar to a website, but instead of actually making HTTP calls to some server, the pages would be directly served up from within the application hosting the WebBrowser control. This has the added benefit that I might be able to reuse some of the HTML code we’ve labor over in the web application.
There are plenty of places on the Internet that will show you how to set the DocumentText property of the WebBrowser control, but that’s woefully inadequate for what I need. For starters, setting just the HTML of the control doesn’t allow you to load images or linked CSS files from memory.
I then read about using the “res” protocol which allows URLs that are redirected to a resource file on the file system instead. This was encouraging because it meant that if I substituted res as the URL scheme instead of say http I could then pull additional resources from memory instead of a remote server. This is a little more difficult to do in .NET because it uses the older style Win32 resource format, but it is doable.
Unfortunately, that still falls short of what I need. I would like to get the whole browsing experience. Page-to-page navigation, images, linked CSS and script resources, postbacks, etc…. I was hoping to find a way to hook into the WebBrowser control so that it would think it’s accessing a remote server, but in actuality, everything was coming from the local process memory.
Then I read about Asynchronous Pluggable Protocols and I think I might have my answer. Based on what I’ve read on MSDN, it would seem that I could register a protocol that when processed will call my code instead of the remote server. For example, I could register the protocol “in-proc” and use it in a URL like this: in-proc://some/identifier. Then when the browser encounters the in-proc protocol and has no built in handler for it, it will ask my code to handle it. I can then do whatever processing I want for that URL, whether it’s get an image out of a resource file, generate HTML, etc…. and return the result to the WebBrowser control. At least that’s my understanding of it.
I think if I could register a custom protocol and then make sure my generated pages use that protocol instead of HTTP, I could use the WebBrowser control as a reliable and robust UI but without the overhead of doing actual network IO.
I’ll let you know how it goes. 
UPDATE: I found an article on CodeProject that accomplishes most, if not all, of what I’m hoping to do.