Lists Home |
Date Index |
True and we are all in a tricky position. HTML
won't go away though. It will still be the easiest
way to do some ubiquitous tasks, but it becomes
less of a requirement for application building.
1. Not nearly as many middle tier vendors have
migrated to the web as some would believe. There
are a lot of fat-client/local hard disk applications
both in the field and in production. Performance,
security, lack of good QBE features, etc. have held
back the web. Not everyone voted with their feet
in the way CNet.com might lead one to believe.
2. The migration onto the web has been occurring
in some of these markets in the edge applications.
In other words, wherever an application really does
need extraprise communications, HTTP, UDP, FTP and
so on are used. But wall to wall, it hasn't made
good sense. The browser never won; it just got
Bacchus's seat at the tabletop in webValhalla.
3. .Net and managed code change that but not because
the problems were fixed but that the underlying framework
was reworked in the direction of the web by making XML
ubiquitous and service-oriented development a requirement.
Longhorn completes that rework. It forces the hand of the middle tier
vendors who now MUST begin a massive rebuilding of
their soon-to-be legacies that were last year's demoWowsers.
On the other hand, Longhorn seems to provide a middle
ground between the web architecture and the local LAN
desktop environment. It's always been obvious that
the web architecture was not an overarching all consuming
architecture for all computing applications everywhere
all the time. It's network plumbing plus some syntax
that is cheap and convenient to use. It reduced the
surface area for building large distributed hypermedia
systems, and that's fantastic. It is not the final solution
for app building. In Longhorn, the URI is not a requirement
for navigation. Even the navigation object isn't a requirement.
The state persistence capabilities improve. Business rules
don't have to live on the server. There are options and
we have to be smart about applying these.
4. At the same time, Longhorm gives middle tier some breathing room.
RFPs that have been insisting on last year's .Net or a
'web-browser only' application will be pushed back because
rightly, the middle tier can respond, 'if we do that
we have to replace it in three years', so the need to
accelerate web applications is less even if the need to
master some new languages and a new framework is more.
This changes the rules of the game.
Even as the IT budgets have gotten smaller, in three
years, some of that will turn around (the economies will
rebound) and the time to buy completely new state of the
art systems will be fairly close to exactly when Longhorn
is ready for prime time. The target for nextGen systems
just moved out three years and can have a very different
character than that predicted by many not very well
That is why I say to the opponents of Longhorn: Threats
and howling about openness won't do more than stir up
the dust. While you still have time, open up the documents
and begin to figure out what is good about the architecture.
If the reply is, "Absolutely nothing" (War, what is it good for!)
then selah. But if you bet wrong, it will be a potentially
fatal bet. So I'd drop the time wasting Spy Vs Spy
stuff and buckle down to some serious analysis.
"It don't matter what you think if you're drinking bad water".
From: Didier PH Martin [mailto:firstname.lastname@example.org]
You need the right technology, the right sales
pitch, and yes, some innovation. Threats get
you absolutely nothing this time because
technology companies are going to refuse to go along
with a campaign that leaves them less competitive.
May I add also that less cash than in the 90s is available.
Didier PH Martin