.comment: Good Idea or Wacky Fantasy?
Linux is Not Windows. Good.
There is out there somewhere a project that proposes to make Windows plug-ins available to Linux browsers by firing up a copy of WINE and running them there. I've seen some discussion of this on KDE lists lately, and it strikes me as a not-very-good idea for several reasons.
The first is that Linux is not Windows. The second is that WINE, even if it worked reliably, which it doesn't, does not make Linux into Windows. The third is that it's a mighty tall and rickety stack of stuff that this project proposes to balance.
(In the same vein, the commercial products which encapsulate an actual copy of Windows in a nice, safe, padded cell run under Linux are also a little goofy. I once used VMWare to prove that it's possible to run Microsoft Bob under Linux. This was for a book, and I laughed loud and long as I did it. As a meaningless gesture, it was nearly an art form. But if I really felt the need to run Microsoft Bob, I'd run Windows until the treatment became effective or the medication was adjusted.)
The Windows plug-in project reminds me of the only method ever available to run RealPlayer under OS/2. One had to install the Windows version and then configure the browser to fire up the built-in copy of Windows -- a huge suck of time and resources, when it worked at all, which was less than when it didn't. Many of us argued at the time that inclusion of Windows in OS/2 would be the death of the latter, because it removed the incentive to develop native OS/2 apps.
So while if your heart is set on running Windows plug-ins from your Linux browser I think you should devote your best efforts to bringing that about, I also think there's something screwy in kludging Windows code onto a Linux machine.
There is one area, though, where compatibility is important, and that's in file formats -- in the ability to read and write to the various Microsoft formats.
It strikes me as a good idea that the people at Ximian are doing a plug-in thing for Evolution which provides Microsoft Exchange compatibility. The plug-in will be neither free nor open source, but that's between Miguel and RMS, neither of whom is particularly shy. I wish Ximian well with this project, even though I doubt I'll buy a copy from them.
Unless . . .A Fiendishly Clever or Monstrously Stupid Idea: LUPI
It was after I'd read discussion of the Windows plug-in adapter but before Ximian's announcement that I started to think that we may have been looking at the whole idea of plug-ins in exactly the wrong way. From this thought my still-embryonic notion of the Linux Universal Plug-In Interface was born.
We have CUPS, which works on any system to simplify the process of printing, always a thorny issue in Linux. We have XFree86 which, for better or worse, does handle the graphics hardware on most machines. We have font servers which work for all applications across the desktop.
And we have scores of independent productivity application projects, each busily hammering away on developing filters for alien file formats. The OpenOffice filters, I am told, now work pretty well; if so, they are alone among dozens of filters that work to some extent some of the time but not well enough for serious work. Like it or not, to be incorporated in the enterprise or to be used where document interchange is necessary, Linux must be able to read and write to Microsoft's file formats. This is not a desirable thing -- Microsoft's formats tend to be pretty gaseous -- but it is reality, and it will remain reality unless and until Linux achieves that critical mass on the desktop that, absent such format compatibility, it will never achieve.
So far, we've been stuck with buying VMWare or Win4Lin, plus Windows, plus Microsoft Office -- when all we've really been seeking is the ability to read and write Microsoft-format documents, by which I mean revision marks, the color-coded nonsense that lets everyone in a group have his own pastel say, black-lining, and so on.
In a flash -- of brilliance or insanity, I cannot say; all I know is that it was a flash -- it struck me: the Linux Universal Plug-In Interface, LUPI (pronounced "loopy") for short.
Here's the idea: a common API for file filters and plug-ins across the Linux spectrum, such that they would be as available as typefaces are. One set of filters is written, maintained, and by the user installed, and there they are, no matter what word processor, spreadsheet, presentation program -- whatever -- you use. The developer of a word processor would need to spend no time developing filters; instead the hooks for them would be all that would be needed. Meanwhile, the tremendous amount of effort used to develop a multitude of identically no-good filters could, if combined, crank out very good ones and stay current with new ones and changes to old ones.
It would also mean that you could read just about any document in a browser, because I'm thinking here of a pretty broad plug-in specification. It would provide a single target for others seeking to write plug-ins for Linux, but who have had to chase a moving target -- several, actually, because working Linux distributions have forked considerably. To me, this is a lot more elegant than balancing WINE atop a browser and a Windows plug-in atop it all.
This would additionally open the market for those who, like Ximian, wish to offer a proprietary plug-in. Those who, say, prefer KMail would be able to fork over the loot, download and install the plug-in, and be Exchange-enabled.
Now. This isn't to propose that all applications come to be able to do everything, which would, for the time being at least, be crazy (though I can foresee a time when the desktop will be nothing but a plug-in loader -- think upon it). Applications will continue to call other applications much of the time. On the other hand, I just clicked on several graphics files of varying formats in Konqueror, and they all just appeared, right there in Konqueror. I clicked on text files, and they appeared, again, within Konqueror. But a KWord file caused KWord to fire up, and a StarOffice file caused StarOffice to load. There's no reason to load the whole program just to take a look at a file. With a common filter API, there would be no need to do so.
Coming from the other direction, projects like HTML editing would be eased by users being able to create their pages in the application with which they're most comfortable and simply export. A lot of word processors and presentation graphics apps have HTML filters, most of which are less than all-inclusive. Again, having just one to maintain would result in one that worked well; the user would then be limited only by the capabilities of the application itself.
There has been talk of projects in which the various desktop projects could collaborate in a spirit of genuinely productive harmony. This is one that would bring them together and bring in others as well -- developers of free-standing applications, the Mozilla crowd, not inconceivably some kernel hackers. The idea, I think, is philosophically pretty elegant, because it would bring reuse of code to a whole new level.
Nor, best I can tell, would it be all that difficult to implement.
Solid state disks (SSDs) made a splash in consumer technology, and now the technology has its eyes on the enterprise storage market. Download this eBook to see what SSDs can do for your infrastructure and review the pros and cons of this potentially game-changing storage technology.