Sanjay,
I took a look at the article you inspired your worked on, and my past on the CLR team forces me to warn you that there is a design flaw in the architecture of this app that could potentially generate Explorer crashes when there is more than one add-on written with .NET but requiring different versions of the runtime. Writing this type of extension in managed code is not a good idea until the CLR will have in-proc side-by-side.
What could happen is that depending on the order of the loading of the add-ons, a different version of the CLR is loaded in the process. THere can be only one instance and it cannot be unloaded, so once this is done, if addon X loads version N of the CLR but addon Y requires version N+1, you will get a critical failure in the Explorer process.
If you used this technique for IE instead of Explorer, you would still have the same problem: the only difference would be that it is the browser that crashes instead of the OS shell.
Concerning the more mundane problem of how to use the API in this case, the simplest way from the development standpoint would be to hit the SOAP interface. You will simply have a helper class in your project and talk to that object, while the infrastructure will take care of the (de)serialization of the data. This project is either a WPF or a WInForm project, so if you are using VS 2008 you need to use a reference to a service and follow the instructions you can find in an earlier posting of mine in this forum to find out how to call the service methods correctly.
I really like your idea and am very curious to see how it will pan out.
Be aware that the terms of use require you to identify entries coming from Live as such and to distinguish them clearly from the others.
I am curious: how are you planning to handle relevance when you merge the lists? Let's suppose that G and us return a set of results.
Some results will be on both lists, some will not. How would you decide what appears in first position and down?
HTH
--Alessandro
