xml-dev - Re: Alternatives to browsers (was Re: Alternatives to the W3C)

[Len Bullard <cbullard@hiwaay.net>]

David Megginson wrote:
> 
> Actually, Mosaic was doing that back in 1994, wasn't it?  At least, I
> remember spending a lot of time fiddling with MIME types to invoke
> different Linux apps.

We've had helpers as long as I can remember and that predates MIME, but 
these aren't helpers.  They will be alternatives to using XHTML. 
MAC86:  
ideal for the next generation of webApps.

> Actually, while this approach sounds good, it will give the sysadmins
> and security directors at, say, Boeing or the DoD, horrific
> nightmares.

The nightmares are not just security, but the hell of managing unstable 
apps that like to desync by reinstalling extant objects with
incompatible 
interfaces:  DLLHell.  In any case, if the sysAdmins aren't contracting 
for provably conformant apps, they are negligent.  
 
> It's already bad enough having to keep track of the (many) security
> bugs in browsers, approved plugins (BAN 'EM ALL!), and mail-readers,
> especially when *some* big vendors consider gaping security holes to
> be essential user-friendly features.  Add 40 or 50 helper apps, and
> you've multiplied the risk beyond the ability of most IS departments
> to even pretend to cope.

It is because everyone downloads willy-nilly for free and without 
adult supervision.  So?  We could all go to thin clients with 
configured servers:  used to be called a mainframe.  Our CEO sat 
me down a few years ago and explained to me that he liked that 
idea very much.  Why?  He felt it his perogative to control precisely 
what was on the machines he paid for.

> I still think that the biggest client-side use for XML
> is to send complex state information to a Java applet or to (yech)
> ECMAscript running inside a browser.

Data islands and CSV files are a good way to save reconnecting 
every time one wants to call a window with a dropdown in it.  
I don't think it much of an improvement or opportunity as 
much as one more bag'odata trick for getting around a 
stateless system.  The main problem with the XML/Java applet 
web server system is that it is possibly the most unproductive 
programming system design environment I've ever used.  Give 
me a nice VB environment that lets me whip up an app in a 
day versus one that takes a week to a month and begins 
to exhibit bugs the first time someone updates the MDAC, 
the common controls etc.  Really, the hardest problem 
is version control in a roomful of cats, rocking chairs, 
and obstinately swinging tails.

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
Please note: New list subscriptions now closed in preparation for transfer to OASIS.