OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help


RE: ??? (was RE: A simple guy with a simple problem)

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.


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

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

> 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
	--Douglas Hofstadter



To unsubscribe from this elist send a message with the single word