I've got my vpc image set up with XP, VC++, WDS2.6.5 and the various SDKs. I've got the code from last time, and I can register a COM object via a ProgId to handle the "msfeed:" protocol. But that's only half the story. I need to tell WDS what urls to index - at least where to start.
This is easier said than done. To quote the original MSN Desktop Search documentation:
After the protocol handler is registered, use the AddDefaultUrl method in the ISearchCrawlScopeManager interface to set default crawling rules to include and exclude particular URLs and child URLs
It doesn't mention where ISearchCrawlScopeManager comes from or what object implements it - do I implement it, or does WDS? Can I get to it from another object, or do I have to CoCreateInstance it?
Questions to keep you awake at night. I can put you out of your misery - ISearchCrawlScopeManager gets passed into ISearchProtocolOptions->GetDefaultCrawlScope. Clear as mud, eh?
Given this brick wall, there's only one thing to do - implement something. I'm going to create a COM object that implements ISearchProtocol, as this is the main interface that WDS is expecting. This will be the Sticklebackplastic.MsFeedProtocolHandler.1 object we said would handle "msfeed:" so make sure to ignore these instructions and keep the ProgId! I've given this object a threading model of "Both" for the moment. Easy option. I've also created my own trace category, and used the ATLTRACENOTIMPL macro in each method. That, coupled with ATL_DEBUG_QI should report any activity on that object, including unimplemented interfaces. (I could paste the code here, but it's long and not currently very interesting and this post is going to be long enough without it, so just download it all at the end...)
You're going to need DebugView now - atl will write debug info when one of my unimplemented methods is called, or when an unimplemented interface is requested.
But to get that info, I need the code running, and the only way I can get the code running right now is to register the dll.
What I really want WDS to do is get my request to register the protocol handler, fire up the object via it's ProgId, and ask for an interface, or call an unimplemented method so that I can see what to implement next.
The only problem is a bug in 2.6.5. WDS just sits there, oblivious.
You have to give it a bit of a kick, either by exiting WDS and restarting, or by selecting "Index Now" (which you might have to do a couple of times before it actually does the trick). Now, the protocol handler will get created by WDS, and it will ask for ISearchProtocol. It also asks for ISearchProtocolOptions, which hasn't yet been implemented. (I also get asked for ISearchProtocolThreadContext, which is defined in the Vista Windows SDK. I'm going to ignore that for now.)
Now I can implement my GetDefaultCrawlScope, and call AddDefaultUrl with a default url of "msfeed://localhost/". Going to the search options dialog shows this url with a checkbox as one of the things being searched. Looks like we're off to a good start.
You can add more than one url at a time. I could add "msfeed://localhost/" and "msfeed://localhost/matt/". Only the first would show up in the options dialog (perhaps because matt is a directory under localhost?) Add them in the opposite order, and both show up. Go figure.
Another somewhat annoying thing is that if I unregister the protocol handler (using ISearchManager->RemoveProtocol) it doesn't remove it from the options dialog.
There's more to ISearchProtocolOptions than just GetDefaultCrawlScope, but nothing else is being asked for yet, so I'm going to leave it at that.
Next on the agenda is implementing ISearchProtocol.
You can download the current code here.
Subscribe