Archive of UserLand's first discussion group, started October 5, 1998.

Re: HTML engines in OSes -- what does that mean ?

Author:Robert Krajewski
Posted:6/3/1999; 10:05:11 AM
Topic:HTML engines in OSes
Msg #:6979 (In response to 6966)
Prev/Next:6978 / 6980

It's not so much that HTML rendering belongs in the OS as:

* It should be a standard service with a well-defined interface. It should be possible to invoke the service without regard to who implemented it.

and

* The OS vendor should arrange for (at least) one implementation of said service to be installed with the OS. (But perhaps the OS vendor doesn't actually right the code.)

Any programmer worth his/her salt recognizes an HTML renderer as just another piece of user-space code, albeit an important one in the connected era. But HTML itself is nothing special -- some other whizbang model might appear in the future.

As far as Internet Explorer on Windows goes, it *is* a standard service, and the interface is well-defined. In fact, it is well-defined enough that it can be reimplemented from outside Microsoft -- there is a Mozilla project working on this.

Unfortunately, ugly reality intrudes in two ways:

1. IE and Moz implement different sets of IETF, W3C, ECMA (Javascript), and vendor standards, or the same standard in different ways, so absolute behavioral similarity is pretty much impossible to rely upon. If you care about, say, VBScript, or layers, this is a big issue.

2. Because COM does not provide an easy way to invoke a service generically, the Moz control must install itself as the implementation of (a) GUID(s) initially assigned to Microsoft implementation(s). But what if some application specifically needs MSIE functionality ? Maybe COM+ solves this, but even COM categories are too weak to solve the problem. Note that one solution, which MS could implement, would be to move the real factory for MSHTML out of the factory for its currently assigned GUID to some other GUID, and kludge some kind of redirection so that Moz wouldn't have to overwrite MS in the registry. (Generally, being able to indirect one factory to another in COM would have been a cool feature -- I could have used that on a past project.)

Note that the Cyberdog framework made flexibility like possible, because the service abstraction was a native part of OpenDoc. Oh well. One interesting follow-on issue for Apple, once they've got the bigger things out of the way is, what are they going to do about the component architecture for MacOS X ?

There are responses to this message:

This page was archived on 6/13/2001; 4:50:35 PM.

© Copyright 1998-2001 UserLand Software, Inc.