DonnyEMU wrote:
Microsoft and rightly so saw the fact that http telnet and ftp are protocols just like SMB and other existing protocols should be built into the OS.. I would like to see this approach taken in AmigaOS, and then the browser just becomes an application that enables these protocols.
Conversely, it's great to have one program that does everything. (I can't bring myself to consider filemanagers that won't preview images anymore.) But then, when do you ever stop using that program? And how much longer until that program becomes an 'OS,' as happened to Windows itself?
You can't disable or remove IE because it is based on integrated protocols which I could argue should be part of the OS anyway, not an add-on..
You can from '98, you just get left with Windows 95, in terms of file management. XP is DOJ-compliant (where "allow disabling, to some extent" has been taken equal to "remove"), so people don't try so hard. MS have a valid point in so far as developers should be able to 'link against' IE if they want, but they're also convicted monopolists, so government theoretically had the right to say "f*** off, you already own the planet."
I would just say that it's all how you implement them. I would love to see an HTTP-Handler built into the AmigaOS that is an integrated as data types are..
Well, for one thing, the protocol implementation should probably be separate from the renderer. This is theoretically true on *NIX, or at least could be with ease (enh, the W3C has a http lib, right, I forget what it's called?), to the extent that you could even have as many http handlers as you want (libbob'shttp, libshirley'shttp), but of course, there's also the freedom for the libraries to have completely different interfaces. (Note that there *are* drop-in, compatible library replacements in use on the planet, under flavors of *NIX that allow that sort of thing... Lesstif versus Motif, for instance; at least, I *think* that one's a drop-in.)
Better to consider are the UI and sociological problems. It's a subtle one, since consistently is normally good, but when the underpinning is "invisible," a user isn't
forced to be aware of who's code their running. Now let's say libralph'shttp has a bug that filters all references to the existence of the Republican Party. Is your user aware if she's using Ralph's version or not? What sort of hoops must she jump through to find out? Is she going to realize there's a problem in the first place, or does she keep voting Libertarian despite a strong and overwhelming desire to invade Iraq and restrict the rights of homosexuals? ;-)
That's the
UI problem. If you don't see it, you may or may not know about it, and from this is "DLL hell" begat.
The sociological problem is that, with consistency, all this very fancy code -- maybe it's hard to imagine a Quake datatype, to play .WADs, but how about one to handle or edit 3D models? -- gets hidden behind the same old system UI. "Great?" Well, sure, for the user, at least if they don't accidentally install Ralph's lib. But many developers, even when not coding for profit, usually want some recognition; they want a "brand." One way around this is to be Apple, and simply tell developers to suck it up, but software that is both good and easily identifiable has an unfortunate tendency to propagate faster than software that's equally good but stays 'behind the scenes.' To the extent that even Apple's official stuff has that shiny metal (woodgrain?!) skin on it, to remind you you're using "the real thing."
You can get around this for a while, but all it takes is one WinAMP to blow a hole in the side of the boat.
