I agree that the events of 9/11/2001 changed everyone's perception. The situation is really the same it's been since the 1970's oil crisis, let alone since the first attempt to bomb the WTC almost ten years prior.
Had real leadership been able to step up at that time to acknowledge that true security depended on energy independence from oil *and* nuclear sources, we'd have had a thirty year head start toward avoiding this mess we're finally perceiving first hand.
I was a teenager back then, but it was clear to me from the popular culture that the problem was at hand, yet in reality Carter was getting laughed at for establishing solar energy tax credits. In fact his response was pretty weak, but a start. Blinded by greed and lack of will, we are. Putting a man on the moon was trivial. Planning a truly decentralized democracy seems near impossible.
My favorite pop culture quote, from "Three Days of the Condor", 1975...
TURNER: Do we have plans to invade the Middle East?
HIGGINS: We have games, that's all. We play games. "What if...?" "How many men...?" "What would it take...?" "Is there a cheaper way to destabilize a regime?" That's what we're paid to do.
TURNER: So Atwood just took the games too seriously. He was really going to do it, wasn't he? Supposing I hadn't stumbled on the plan? Say nobody had?
HIGGINS: Different ball game. The fact is, there was nothing wrong with the plan. Oh, the plan was alright. The plan woulda worked.
TURNER: Boy, what is it with you people? You think not getting caught in a lie is the same thing as telling the truth?
HIGGINS: No. It's simple economics. Today, it's oil, right? In ten or fifteen years... food. Plutonium. And maybe even sooner. Now, what do you think the people are gonna want us to do then?
TURNER: Ask them.
HIGGINS: Not now. Then. Ask them when they're running out. Ask them when there's no heat in their homes and they're cold. Ask them when their engines stop. Ask them when people who've never known hunger start going hungry. You wanna know something? They won't want us to ask them. They'll just want us to get it for them.
Well, itís for Macromedia developers in the same sense that Win Forms is for dotNET developers and WebStart is for Java developers. Itís competition, I am sure they want more developers. With a good strategy, they deserve peopleís attention. With good delivery of the platform, they could win some. Flash is the #1 plugin on the web, and is the foundation for Central. Central as a vision goes way beyond Win Forms or WebStart.
A service-oriented architecture would be able to plug into server-side and desktop portals. I think this whitepaper expresses the vision of the desktop beyond the browser better than anything else Iíve read. How they deliver on the vision is the key. Portals belong on the desktop, and I think they will get there in the long-run. If Central is successful, maybe it wonít be so long.
I would expect this strategy to shake up Redmond the way Mosaic did almost ten years ago now. Microsoft has not put a vision together like this and will have to respond with more cohesion than what theyíve done lately with InfoPath, Office 11, etc. Whether or not Central succeeds, it should at least move the primary move and shaker up to a new level of vision it probably did not have last Tuesday.
What could have been done otherwise? There's no telling. Paul Snively has some suggestions as does IBM's DeveloperWorks.
The Register writes about NT 4.0, which is not so old that the architecture should be so different from Windows 2000, XP, or Windows 2003...
In a surprisingly candid admission, the company states that fixing NT4.0 is simply too difficult.
"The architectural limitations of Windows NT 4.0 do not support the changes that would be required to remove this vulnerability," Microsoft says.
The approach goes right to the heart of points I have been raising with "portal" proponents in IT shops. Occassionally connected computing. Some ideas that seem well thought-out.
BAM! There's some excitement in this as some concepts sink in.
Maybe it is not so ironic that just as CORBA was reaching a reasonable level of maturity (including viable open-source implementations), XML-RPC mutated into SOAP and took on a lot more baggage than I believe was originally intended. The CORBA-ish aspects of SOAP will take *years* to mature in terms of the number of usable, interoperable implementations, as well as in terms of well-known, reliable patterns of application usage.
I believe CORBA was more complex than necessary for 80 percent of the use cases. The collection of SOAP-related specifications are even more complex and less proven.
SOAP is inevitable though. I suspect simpler usage models would emerge if the standards committees and large vendors would step aside and let developers compete for real solutions.
Observing relational database development and object database development way up close for about 20 years, I'd say space-based programming is a simpler, more effective model for 25-75% of the situations where a relational database, object database, or message bus applied. (Yes, that's a pretty wide percentage, but I'm hedging my bets since it is not based on any real statistics. Even 25% of these sitations is a *large* number representing a good deal of time and money.)
Space-based designs are applicable to "application-specific storage", many "workflow" and "web services choreography" situations, many "EAI" or "message-based" situations.
MIME-RPC seems to have the simplicity of XML-RPC, but with some improvements.
Not very active though... maybe the recent traffic will lead to an few implementations.
Contents for March 23rd
ABSTRACT: Realistic Compilation By Program Transformation, R. Kelsey P. Hudak
Using concepts from denotational semantics, we have produced a very simple compiler that can be used to compile standard programming languages and produces object code as efficient as that of production compilers. The compiler is based entirely on source-to-source transformations performed on programs that have been translated into an intermediate language resembling the lambda calculus. The output of the compiler, while still in the intermediate language, can be trivially translated into machine code for the target machine. The compilation by transformation strategy is simple: the goal is to remove any dependencies on the intermediate language semantics that the target machine cannot implement directly. Front-ends have been written for Pascal, BASIC, and Scheme and the compiler produces code for the MC68020 microprocessor.
My thoughts, which I've repeated in a few different forums already:
The underlying mechanisms for the CLR as well as for the JVM *are* dynamic. The problems for making these systems universal are in the necessity to use nearly the entire language model of C# or Java, rspectively, in order to achieve any kind of integration.
A better approach, IMHO, would be to make integration more abstract and more loosely coupled than the "shared object model" of the CLR or JVM.
Components written in various languages should be integrated via a simpler, asynchronous, shared-nothing, message passing model. Then those components could be instantiated in the same OS process, a different OS process, or on a distinctly different host on the network, without having to alter the mechanism for integration.
A virtual machine in this model would offer a reusable implementation of garbage collection, component instantiation, time-sharing, channel discovery, message formatting, optimized "intra-OS-process" message passing, and an instruction set for sequential processing. A universal virtual machine would not require a shared-memory, monitor-based, object model.
I would choose Scheme as the "instruction set" of my virtual machine, and not make language implementors deal with low level CPU models.