Since we're a two person team, my "deployment" method was to simply check this .reg file into source control and tell Brian to run it on his machine. Large teams probably already have a way to deploy scripts like this to every team member's machine. Large teams might also have multiple editors installed on each machine (for different source branches or projects). For brevity, I'm skipping over these issues here.
URL Format and Parsing
Now that your URL protocol is registered, you can test it by typing a link starting with your protocol (e.g. drl://test) into your web browser. You might have to click through another security warning, but your executable should be launched and the full URL will be passed to it as a command line argument. Now your next coding task is to parse the URL into a file name and object, open that file, and open the object editor automatically. I'll leave the details to you, but if you already support double-clicking your editor files in Windows Explorer, then you've already done 90% of the work.
My URL parsing is bare bones to minimize overhead. I just used standard C string functions to extract the file and object name and I don't worry about properly encoding/decoding special characters (all our file and object names are alphanumeric without spaces anyway). But I did follow the standard URL "query string" syntax so that if I do use a legitimate URL parsing library, it will be trivial to extract the values. You can use any format, but I prefer something that is short while still being human-readable. Our format is simple:
drl://relative_path_to_file?obj=object_name
Making URL Links "Paste-able"
At this point, I thought I was finished with URL protocols, but I discovered that unlike standard http:// protocol URLs, if you paste a URL with a custom protocol (like drl://) into most e-mail clients (like Gmail), they don't automatically get turned into "click-able" links when you send the e-mail. Of course, you can manually make links with custom URLs into click-able links by using your e-mail app's GUI, but that is not quick and easy enough for me. I just want to paste the link and send it!
After some research, I learned that custom protocol URLs aren't automatically click-able in most e-mail clients for security reasons. Unfortunately, the standard workaround is a bit gruesome. The "done thing" is to use a standard http:// URL that sends the user to a webserver, then the webserver redirects to the desired custom protocol URL. It's sad to complicate our tool chain with a webserver like this, but that's what we've done.
So now this URL: http://drool.ws/relative_path_to_file?obj=object_name
Gets redirected here by our webserver: drl://path_to_file?obj=object_name
Now everything works. There are many ways to redirect a URL, but probably the easiest way is to use Apache's mod_rewrite and a regular expression rule. I recommend that you don't do any actual parsing of your URL in your webserver, just do a simple find/replace and then redirect. I prefer to keep all the parsing in my editor and involve the webserver as little as possible.
UPDATE: As commenter F Fulin suggested on #AltDevBlog, an alternative to redirecting is to use a standard, but out-dated, protocol (e.g. gopher://) instead of a custom one. If your e-mail client automatically highlights links using a protocol (and you don't need to use it for anything else) you can hijack it and avoid redirecting.
More Editor Integration
Once you have this much working, everything else is gravy. Now that we can go from an Object URL to a specific file/object in our editor, the obvious next step is to make it easy to extract Object URLs from our editor. When you right-click objects in our editor, the context menu has a "Copy URL" option. Selecting that copies the Object URL for a particular object to the clipboard.
