views:

253

answers:

4

I am designing a web app that has some information that needs to be transferred to a client side (non-browser) application (i.e. Outlook). Assuming the client side app has an API of some sort, I need for the web app to trigger the client side (based on a user clicking a link) to get the information and transfer it into the client app through it's API.

My first thought would be to write an ActiveX control that I can pass a secure code to that then uses that information to talk back to the web app through a web service I create and then the ActiveX control can implement the interface into the client side app (i.e. Outlook). Based on what I have read, this is doable with ActiveX.

My problem is that ActiveX won't work in Mozilla browsers or Chrome which poses a real problem as I need this to be multi-platform. I've read about NPAPI which is supposedly the equivelent native technology. I also read about plug-ins for Firefox and Chrome that supposedly support ActiveX, but they aren't native. I need to have native out of the box support so that users don't have to do anything special, just click and run. So here are my questions:

1) Is ActiveX my only option for IE?

2) Do I need to develop ActiveX and NPAPI to support all clients?

3) Is there a better way to do this that I am not aware of? I am open to other technologies since the focus is on a seamless user experience.

Thanks for any insight!

A: 

im afraid one of your possible solutions would be to develop a plugin for every of the browsers you'd like this app to work with, just like google did with gears

however you can always try to do the trick with a java applet but I don't know if the browser security policy will allow you to talk to an app such as outlook, i believe it will

cheers

PERR0_HUNTER
It will, but it will display a dialog requiring the user to "trust" the control. The dialog isn't particularly specific about what will happen, so sometimes it scares users half to death :-/
Taxilian
A: 

If I understand your requirement correctly, I don't think anything is going to be seamless. You require some kind of module to be downloaded onto the client machine that will have access to the their local system resources. Any decent browser is going to throw up horrified warnings to the user.

dommer
Thanks dommer. I am okay with the user having to download a component (like ActiveX), I suppose it's a necessary evil, I just want to keep it simple and would prefer to use one technology as opposed to 2 or 3 based on the browser.
John Virgolino
A: 

Depending on what kind of information you're transferring, it's possible you could get Outlook to open and process it when it's downloaded. For instance, Outlook is normally set as the default application for .ics (Internet Calendar) files. When I download a .ics file, Outlook will launch, and open the file as a Calendar entry.

So, one crazy idea would be to write a small application the user would install on their system. That application would be registered as the default program for a unique file type of yours. When you want to transfer the information, just download the file as an attachment. Your program will be called to process it. Your program can then use the Outlook API to send the data into Outlook in whatever way you need to.

If the interaction is not appropriate to a single file, you can still use a dummy file. It's purpose would be to launch your small client-side program and give it instructions. Your program could then communicate back to a web service of yours on one side, and through the Outlook API on the other side. You would be able to do anything you like in that environment, especially if you also create an Outlook add-in.

I haven't done Outlook programming for several versions. It's possible that with the Outlook 2007 and Visual Studio Tools for Office, you may be able to combine some of these pieces. The main benefit is that you would not need to worry about the browser at all.

John Saunders
A: 

ActiveX only works on IE, but NPAPI works on Firebreath, Chrome, etc.

You could use the FireBreath project, which provides a relatively easy to use abstraction for creating a single plugin interface that will work as an ActiveX control or a NPAPI control.

the project homepage is here: http://firebreath.googlecode.com

Despite the lack of an official release, it's really very close to a 1.0 windows-only release; which it sounds like is all you care about.

For "quickstart" information, check out this wiki page: http://code.google.com/p/firebreath/wiki/CreatingANewPluginProject -- there is a python script that will generate a sample project, you can be up and running in probably 30 minutes with a basic plugin.

Also, join the mailing list -- I'm the primary developer, and I assure you that we will answer queries promptly if you have problems getting started. =]

Taxilian