More Third-Party Innovation: XMLTerm
Monday September 27th, 1999
R. Saravanan has sent in to us a copy of his recent posting to the xpfe and unix newsgroups. He writes:
"XMLterm: an experimental Mozilla terminal
Real time chat ...
An early prototype of XMLterm, an XTERM-like terminal program implemented using the Mozilla layout engine, is now available to tinker with. XMLterm aims to add graphical and hypertext capabilities to the XTERM command line interface, while maintaining backwards compatibility.
The basic design philosophy of XMLterm is that the user interface is a dynamic XML document. The user and the computer interact by taking turns at appending to this XML document. The plain text content of the XML document, i.e., excluding any markup, corresponds to the plain text that would be displayed by a plain XTERM. The markup in the XML document is used to add graphical and hypertext features. XMLterm uses the Mozilla layout engine to display the XML document.
See http://pages.prodigy.net/hmmanju/xmlterm for more information, screenshots, and downloads. XMLterm is a non-commercial open source project in its early stages. Comments and contributions are welcome!"
Definitely check it out! You can download the source, or, if using Linux, you can download a binary for use with M9. There's a lot to see at that site (and quite a bit not mentioned in his announcement). What are "Pagelets"? I'll let you find out for yourself, but they're worth seeing.
#11 More Third-Party Innovation: XMLTerm
Monday September 27th, 1999 6:30 PM
You are replying to this message
I agree with what you're saying -- you're totally right about the approach the Mozilla project has taken, that XML and JS is a killer combination -- but you're sort of missing my point.
You do rightfully point out that when it comes down to the pragmatics of the real world (as pertaining to most of the web-enabled population) the Communicator suite, or whatever they choose to call it, will be all people ever see. And the design of the Mozilla System (if I can call it that without being laughed at) is such that it accomodates for that basic need very well.
Indeed, it is fine with me too if anybody wants to build XP apps on top of the Mozilla core. Nothing wrong with that. But what happens when the needs of a hypothetical new generation of XP app developers outweigh the functionality provided by the Mozilla core? Should their needs be accounted for, and if they are, does the core become significantly more bloated (or "robust" if you prefer a friendlier word) than is made necessary by the basic requirement of a Communicator product? That's the first question.
The second question is, does it make sense to develop certain cross-platform apps? Does it make sense to facilitate the development of these apps in the Mozilla core? XMLTerm is an example. It makes very little sense to enable such an app to run on the Mac, for example. You bring up the point that native apps would be smaller or more efficient, although you say that this is probably small to. I agree with you: a well-designed core, as this is, will be fast enough and easy enough to code for. But in a world where performance is not an issue, Mozilla seems to be stepping into an odd role: that of Java.
Java can be described as a cross-platform language with a cross platform app toolkit (eg. Swing or the underlying AWT). There are platform-dependent virtual machines to interpret the platform-independent code. Mozilla seems to be built similarly, but at an even higher level of abstraction.
So to wrap up the second question which I started to pose like three paragraphs ago: is this the right place for Mozilla? Is there the need for such a powerful cross-platform core, and if there is (because we might be headed in just the right direction) how can we capitalize on it?