ActiveX in Linux browsers

This is probably a *very* dumb question, but I'm curious as to what technical obstacles exist in order to implement ActiveX. One issue I have is that I don't know the ins and outs of ActiveX but, with the Mono underlayer, some derivative of ActiveX might be barely possible, especially since Gtk# is out and about (though I've not used it personally).

And then there's Java applets, which probably work better anyway since Java was designed from the ground up to support multiple machine and OS types and sandboxing.

But never mind that; Microsoft still holds sway over 80% of the browser market, standards notwithstanding. Should ActiveX be used in a web application?

I see at least the following possible positions.

1 Yes, we should try to capture as much of the server market using a Linux browser with ActiveX compatibility as possible. We might have to do some reverse engineering, though, and maybe include wine or bochs in the client browser for non-x86 equipment. But it's worth it.

2 Yes, but we should only do minimal engineering to get the Web application to work on the main two browsers. We use ActiveX on IE, and applets everywhere else. The two program paths won't be a major problem from a support standpoint. We hope.

3 No, just implement to standards, which may include applets (they are mentioned in the HTML 4.0 spec *). IE can support applets, after a fashion.

4 No, just implement to standards, which may include 1.1 applets. Since the old JVM can't handle anything newer that's what we should use.

5 No, just implement to standards and don't bother with applets, as they're a proprietary solution.

6 Punt on the issue and use JNLP-Java Web Start, with SWT. That way it looks like a native application to the end user. The web browser is only needed for initial launch; so what if it's a piece of crap like IE? :-)

7 Punt on the issue and use JNLP-Java Web Start, with Swing. It'll look different on Windows but that's what we want (since we want the user to know he's using Java), and the browser is only needed for initial launch; so what if it's a piece of crap like IE? :-)

8 Have the browser launch a Windows program after it has downloaded said program securely over the Internet from one's website. Since most users use Windows this will work -- sort of.

9 Use 8 on IE, 6 or 7 on all other browsers.

10 Use the traditional method of downloading a "fat client" from an FTP site (with md5 checksumming to ensure integrity), and just use the Web browser for selling the product. The fat client will communicate with a secure but proprietary server (though the server might use a standard communications layer, such as SOAP or ASN.1).

11 Have the user download C source code for a "fat client", together with links to a working GCC environment (Cygwin works on Windows, for example) and all needed freeware libraries, plus instructions on how to build this mess himself.

12 Have the user download C source code that works in both GCC and Microsoft's C compiler, and instructions on how to build on various platforms, Windows among them.

I'll admit I like 3, 6, and 7, but then I'm partial to Java. 11 might work for certain savvy users. 12 is problematic for various reasons, mostly because the underlying APIs are different.

-- It's still legal to go .sigless.