Custom Protocol Handler vs BDC

I get this question a lot. If I have SharePoint 2007 enterprise version, I can index any repository with Business Data Catalog (BDC). Why should I care about Protocol Handler? Writting Protocol Handler is anyway is a pain in neck, even the experienced C++ developers find it hard to write

So the simple answer is the BDC was designed for knowledge workers (those who Microsoft consider pseudo-programmers) to be able to extract busienss information from Line of Business Application using declarative langauge (XML) as oppose to a regular programing language.

Since the target audience of BDC are knowledge workers and not programmers, its NOT designed to scale or for complex scenerios. Its a very much black box design. You don't really know what happpens behind the close door ( and you probably don't care, if you are not a programmer)

This is what you don't get in BDC

• You have no control over what type of IFITLER ares applied. Agreed, you don't really care if this is just a matter of text extaction from binary documents, but if you really want to emit custom metadata, or links, you do need a good control on how its being handled
  
• You can not do any kind of custom throttling or optimization. Everything is a black box. SharePoint provides some throttling options for content-source, but thats as far as you can go
  
• You have no way to do any network optimization, custom error handling or debugging. If your document is not indexed, well you will in the gatherer log but with standard error message
  
• You can not emit custom security ACL for your document/items to BDC
• You can not control the incremental indexing, new items or deleted items.

• You can certainly specify in BDC definition but nothing compare to protocol handler
• Finally, putting PH developer on the resume is totally different than putting BDC developer :)
  

SharePoint SDK = .NET (Managed Code) + COM ( Unmanaged code)

Ever since I used reflector(a freeware tool to examine any .NET assembly) I check most third party assemblies before using in my code. SharePoint was no exception. I wanted to see how SharePoint communicates with SQL Server. So I started digging but to my disappointment, I couldn't find any references to database related code. But to my surprise, I discovered something entirely different (See the class below)

Most SharePoint data connection usages SPRequest class, which is in Microsoft.SharePoint.library.dll ( This dll gets copied in GAC on SharePoint machine, you will need to manually copy this DLL out of GAC if you want to see all interfaces). Now this assembly in turn usages OWSSVRLIB.DLL ( This dll is under 12\ISAPI folder). Interesting thing is, this is a COM (UNMANAGE CODE) dll, obviously reflector didn't work

So I was disappointed in my quest but I indeed found something which makes me wonder is this an intelligent design decision or simply lack of time?

Proof reading, usability or lack of time ?

I usually stay way from pointing out mistakes but I couldn't resist with this screen. This is in SharePoint 2007, one of the products that brings food on my table :)

So SharePoint 2007 supports multiple operations - Performing action on more than one items with a single button. If you go to "Site Action" | Portal Content and Structure, you will notice that all contents has a checkbox in front of it. You can select more than one content and then pick your action from the toolbar above.

In my test environment, I had few sites, which I created as part of my stress testing and I wanted to get rid of them with a single command, so multiple operation was the perfect action for this kind of stuff. Everthing worked nice and well but the confirmation message screen SharePoint displayed was funny... It appears someone either forget to test this or didnt bother :)