Re: A Modest Proposal

Browsers are supposed to know what to do with a file based on its mime type,
which *every* object coming down an HTTP pipe has associated with it.  Thus,
I don't see a need to specify the name of the application used to view it -
especially since there are usually more than one kind of viewer for a given
file format.  Other than that, hopefully your idea is one that browser
authors are moving towards - making the web browser work more closely with
the desktop using OLE or CORBA or whatever desktop API people finally settle
on, and acting more like a window manager or traffic cop than a simple
viewer, and those crafting the future of HTML should keep that in mind.  The
flip side, of course, is that the greater the number of different file
formats in the average web document, the greater the number of simultaneous
processes needed to view it and the greater the total number of different
programs needed to seamlessly surf the web - this could be a problem.  If all
mathematical equations were inlined as LaTeX, Mac users would be lost (unless
there's a Mac LaTeX viewer I've never heard of).  So, it's a line that should
be walked carefully. 

	Brian


On Wed, 25 Jan 1995, C. Bailey wrote:
> As an alternative (IMHO) I would suggest instead of extending HTML to cope
> with every specialised format one might wish for (tables/spreadsheets,
> mathematical formulae, inline sounds and video clips...) one could, at the
> cost of the luxuries of having these things presented 'in-line' simply
> feed them into software which can handle them, without having to translate
> them into HTML. 
> 
> The idea is analogous to that of the [application] message type in MIME
> (rfc1521) which specifies that a message is to be processed by a specified
> application. This could either be implemented by extending the anchor tag: 
> 
> <a href="filename.type" use="application.name">
> 
> or more flexibly by simply having the browser assign a set of applications
> to a set of filename extensions, similar to the MS Windows File Manager.
> Then when a link to a non-html file is selected, the chosen application
> auto-loads using the specified file and either displays it or executes it.
> This is what happens in certain browsers when a '.gif' file is specified
> in this way, and the extension to other file types would presumably not be
> too complex? 
> 
> Although there are clearly difficulties with this approach (e.g. the need
> for software to read each file type, security issues with executable
> files) I would say that by choosing a few basic file formats (eg
> postscript for page description, LaTeX for formulae) to provide readers
> for (perhaps bundled with a browser) coupled with existing applications
> (eg MS- or X-Window software) one could open up vast new panoramas of
> existing data in every form, leaving HTML as the backbone to support a WWW
> fleshed out with all the data currently inaccessible in unreadable
> formats. 

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com  brian@hyperreal.com  http://www.hotwired.com/Staff/brian/

Received on Wednesday, 25 January 1995 13:28:29 UTC