xml-dev - Re: Extensible browsers

[Len Bullard <cbullard@hiwaay.net>]

Simon St.Laurent wrote:
> 
> If a browser just becomes a set of common modules, with some way to
> distinguish which modules are available, we might be getting someplace.
> This'd take going way beyond the XHTML modularisation we have now though,
> or the relatively simple content-type negotiations between servers and
> browsers that are part of HTTP.

Que bueno.

That's part of it.  Ok.  Now show me how to prove that for even one 
of the content handlers, I can guarantee reliable performance.  
What happens if the system dynamically finds components based 
on the content rating for required reliability?   Consider content 
that can make that request.  For example, RealMedia wakes up and 
tells you that an upgrade is needed, then does it automatically 
and in my experience, very completely.  This is a sea change from the 
last version, so I think they are listening to the users.

Some of the marketing wonks who follow these threads should consider 
asking their logistics engineers if they have them, how does a markup 
system contribute to the outermost performance numbers for MTBF?  
When doing this, one needs to do the Failure Mode Effects Analysis 
first.  Remember, it is a system with lots of layers, each has its 
own failure modes, and overall these can provide a rating for 
the complete system.  By the way, being able to continue operations in 
a "degraded mode" as Winer said, is precisely what is needed.

Can anyone tell us what Windows is doing when it boots up 
in SafeMode?  What is Safe and what is disabled and how 
are the choices made?

Some of us are old enough to remember CALS and the arguments for 
why SGML was chosen.  The rest of you, do a little digging.  This 
isn't about the browser wars. 

len


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Unsubscribe by posting to majordom@ic.ac.uk the message
unsubscribe xml-dev  (or)
unsubscribe xml-dev your-subscribed-email@your-subscribed-address

Please note: New list subscriptions now closed in preparation for transfer to OASIS.