[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ??? (was RE: A simple guy with a simple problem)
- From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
- To: xml-dev@lists.xml.org
- Date: Thu, 15 Mar 2001 08:14:41 -0600
Failover is a good practice. Spreading
redundant operations among different agencies
is a good practice.
No one still in business commits 99.99% 24/7. They try
for it. It is an exercise in gently and
diplomatically explaining to the customer
that all due diligence is applied all the
time to making the system as robust as
possible. Then implement and test, and
field and test. To stay in business,
*read* the requirements carefully and *answer*
truthfully and even more carefully. Pet
the people who do your proposal work; they
keep you away from bad business practices.
Now take a look at schema and ask: who
is the customer? What did they ask for?
What can they afford? What can really
be built for that cost? What would you
propose given all of that?
I think some may be surprised to find
that XML Schemas are emminently affordable
if implemented in common code for what
they are intended to do. In fact,
I'm not sure XML as a common transport
for more than "doodads" is affordable
without them. Cost is more than the cost
to write and test the code. Lifecycle
is more complicated than that. Common code,
as Tim mentions, is key to reliability.
So are common specs because they are how
we get common code.
I'm not sure about the semantic web.
It may be something that takes a long
time to realize a profit.
Len
http://www.mp3.com/LenBullard
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
-----Original Message-----
From: John Cowan [mailto:cowan@mercury.ccil.org]
Sent: Thursday, March 15, 2001 7:25 AM
To: Tim Bray
Cc: xml-dev@lists.xml.org
Subject: Re: ??? (was RE: A simple guy with a simple problem)
Tim Bray scripsit:
> >30 seconds of downtime per year???
> >Presumably you write in assembly language
>
> Bad, fragile software engineering practice
In general, yes. But are you willing to bet lives that
there won't be a bug somewhere in the compiler or support
libraries that surfaces one fine day? Remember, if
it takes you an hour to find it, that's your whole
downtime available until 2121.
> >on the bare metal of mil-spec
> >hardware,
>
> in the computing space, typically less robust & reliable than
> commercial off the shelf stuff with redundancy
Maybe true by now, "milspec" probably doesn't mean what it
once did. But consider how long you have to recover from
various disasters:
Multistate power outages happen about every 30 years.
You have 15 minutes to recover from them, assuming no other
problems.
Catastrophic fires, the kind that leave a city mostly ruined,
happen about every 100 years in the U.S., more often
elsewhere. You have less than an hour to reroute all
communications through a network jammed with emergency
operations and people trying to find out about their
friends and relations.
Catastrophic wars, the kind that leave your essential
support personnel dead (or in the army and unavailable),
happen every 50-100 years. You have less than an hour
to relocate all operations to an unaffected country,
assuming you can find one.
You don't catch me promising 30 sec/yr downtime for
anything.
> Depending on well-debugged existing code/gear is one of the
> the best practices in achieving high reliability. -T
High reliability, yes. Extremely high reliability, the kind
we are talking about here, no.
--
John Cowan cowan@ccil.org
One art/there is/no less/no more/All things/to do/with sparks/galore
--Douglas Hofstadter
------------------------------------------------------------------
The xml-dev list is sponsored by XML.org, an initiative of OASIS
<http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: xml-dev-request@lists.xml.org