Alternatives to browsers (was Re: Alternatives to the W3C)

[David Megginson]

"Simon St.Laurent" <simonstl at simonstl.com> writes:

> XML opens the way for a super-slim 'browser' that's pretty much a network
> interface with an XML parser on it, passing results as requested to a wide
> variety of application possibilities.

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.

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

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.

There is a partial solution, though:

1. Develop an environment where all apps run in a sandbox with little
   or no default access to system resources.

2. Require apps to use a common binary format that can be examined and 
   interpreted step-by-step rather than running machine-instructions
   directly.

Oops!  Look like I just invented Java.  Any venture capitalists listening?


> Either way, I'm looking forward to lots of XML-based apps running over
> TCP/IP and possibly even HTTP.

Yep, me too.  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.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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.