[
Lists Home |
Date Index |
Thread Index
]
Sure, but I doubt you will get the customers to vote for
multiple standards for TV broadcast if it forces them to
have five different televisions. On the other hand, they
are willing to put up with over-the-airwaves, over-the-cable,
direct-by-satellite, TiVO, DVD recorders, and VCRs. They
didn't tolerate beta vs VCR for long although one could
argue Sony decided the market wasn't big enough for two.
What we are seeing may be more like Windows vs MAC and
that continues to this day.
We may want to look at this in terms of developer choices.
When is it appropriate to use the rich client? When is
it appropriate to use the browser? When should we put
as much on the server as we can and when will it be wise
to balance the performance load by fattening the client?
My intuition says that locus of control and distance
determine this. In other words, rules of LANs and WANs.
Some will claim IT makes these decisions based on ease
for their own jobs, but my experience is that varies
by organization. Sometimes the IT guys get to decide;
sometimes the users get to decide. Sometimes it comes
down to cost; sometimes it comes down to performance
and functionality. Every bloody RFP and procurement
group has their own cultural biases.
What we do have are choices here now that we don't have
if we insist on one or the other as the 'winners'. I'm
not sure they are competing in that sense. Will XAML
compete with XUL/SVG? Sure. Is that bad? Not from
where I sit but I've no XUL/SVG investment to defend.
Because we buildhigh performance real time
dispatch applications as well as large databases that
need to interoperate both intra and extra agency, we
need both browser and rich clients. We welcome XAML
to get a modicum of convergence and choice. We welcome
Indigo to lighten the load of building those extranet
databases for standard service oriented architectures.
Our challenge is to get our industry to converge on
standards for that. (Public safety is a late adopter
industry. Otherwise, a death knell would have been
heard for the vendors here because they are a good
five to eight years behind technically.)
Will XAML compete with X3D? In some applications, it
possibly will, but real time distributed 3D is a tougher
competition and XAML might not be able to win that won.
Chrome was a performance dog and performance is the
sine qua non of real time 3D. I don't dismiss it, neither
do I fear it. We will tune and retune our standards to
accomodate the market. Anyone who thinks this is a
"done and done" decision hasn't done this for more than
five years.
What we should learn to do is recognize when innovation
is just perturbation. Markets are actually pretty good
at not buying new and different for the sake of it when
there are no demonstrable benefits. It isn't as if we've
all seen the glossy interface and lost our business sense.
In my domain, we sell to very dense and very difficult
RFPs that over time weed out novelty for novelty's sake.
len
-----Original Message-----
From: Didier PH Martin [mailto:martind@netfolder.com]
Sent: Thursday, November 13, 2003 8:29 AM
To: 'Rich Salz'; 'Bill Kearney'
Cc: xml-dev@lists.xml.org
Subject: RE: [xml-dev] Inside Redhell: Microsoft XAML Blogger Round-Up
Hi Rich,
Rich said:
Ya think it was a fair vote? Let's consider "fair" to mean "follow
standard practices"
If you answer yes, then there's a few court cases to read...
Didier replies:
You probably misunderstood Len, He meant "customer vote". This is the
ultimate vote. You may argue that they didn't have the choice; they may
argue that they do not want choice. Just think for a moment, why the USA is
dominated by a single language even if its population came from abroad and
spoke a different language. Just think for a moment... Your definition of
"standard" may not be the same one as the "market" has. Just think about
that for a moment...
Cheers
Didier PH Martin
http://didier-martin.com
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|