More Third-Party Innovation: XMLTermMonday September 27th, 1999R. 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. Wow! That's really all I can say. Imagine one engine providing the ability to do all the various things we've seen over the last few weeks. And that's only the beginning. As the Mozilla browser and suite is nearing beta, we are really seeing the power of Open Source. Innovation is taking off, and we'll all be better off for it. This is the future of computing and GUIs. Terminal type hardware running an XML interface with an XML document standard. I can't say I really like the examples he uses (the graphical ls - ick), but the idea is fantastic. Imagine typing cat my.tiff and having the image scroll by. I hope this takes off. I have to say I'm dubious. Let me clarify: The XMLTerm idea is a wonderful idea, and it brilliantly showcases the power of Mozilla. However, I think this might be another instance of a trend which might not be The Right Thing. I think Mozilla could be described as a very powerful application core. A browser, an editor, a mail and news reader, etc. are all built on this core. I'll say it again: it's very powerful. So powerful and cross-platform that a trend is emerging, of treating the Mozilla core as an OS in and of itself. This in itself isn't exactly a bad thing -- it's just making use of available technology, as far as I can argue. But it seems like Mozilla may be trying to fill more niches than for which it is needed. It's a strange situation to be in, where the architecture is so damn good that you can do things in it that maybe shouldn't be done the way they are... This is, I guess, a bit vague of an argument. On one hand, Mozilla is incredible as evidenced by these developments. On the other hand, Mozilla shouldn't (maybe) fill the role of an operating system. For example, an XML-based terminal doesn't exactly make sense on a Mac or Windows platform -- should a cross platform core be used? The list of questions goes on. Discuss? I don't think Mozilla is "trying to fill more niches than for which it is needed." Mozilla and Netscape 5 will still be the basic Communicator Suite. If 3rd parties want to build cross platform apps then it is fine with me. I would use Be more if I could get a decent browser and a few other things. This is an example of one of XMLs key benefits, cross platform communication between apps. Sure a native one would be smaller, but this is probably small too. This is one of the reason why MS was so scared of Mozilla at first. Applications written in HTML and JS could be on ever platform which supports the browser. 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? I see what you are saying now. These new generations of xp developers should not expect to get everything they need integrated into mozilla. But then again I cant think of too many things that cannot be done with mozilla now. Any bloat, robust can mean bloat or error proof, they want to add has to be done on their end. Through modified code or plugins, unless it is a killer feature. Most of the apps I see now are just hook up the piece that are in the codebase. I believe that this and that irc client network code has to be in necko. I think the orginial purpose of Java has be tarnished by the web. It was design to interact with cell phones and toasters and not really much else. But it was extended and now its everywhere, except on Be (port people port). I love Java, its a nice language but dhtml is even easier in some cases. not as powerful but easier. If they relly want to run with this idea there is one really good way to do it. Orcale put a microkernel into one of their dbs, I believe its 8i. Lets slap one onto mozilla. Now instead of acting as a vm or an OS, it is the OS. A truely frightening idea for most companies since a browser can do basically everything that most people need (word processing, internet, basic games). I am inclined to agree with this approach. Java is one thing, and MacOS and Windows is another, but here in a kind of creep creep progression, Mozilla is beginning to encroach on all their territory. (for a user anyway) You can already create a full windowing environment, with tools such as word processing etc etc (ok performance isnt so hot, at the moment), and it is easier to develop than a native app for -any- OS out there. I think this is the way to go, and the only real way the networked world can really kick in. Nothing can be 'off-browser' if we want -everything- to be integrated. Not to deny Moz's power, but it's far from an OS! Our beloved lizard, XP or not, still relies on many rather complex APIs in it's hosting OSes. What I'd like to see is a super-tight Mozilla/Linux integration, because then you are talking about an incredibly powerful & tiny combination and thus a CE competitor with amazing potential -- imagine the ease a developer could approach it with. So many people have learned to develop for the web because it's EASY, and opening a platform to that ease is truly compelling. I'm sure this stuff keeps Microsoft awake at night! Looking at the past we know that accessibility of programming has scaled with processor power, so since Moore's law still reigns we're constantly able to create higher-level, more encompassing procedures while making their overhead insignificant. Once can almost feel the bar lowering... I think this lowering significantly increases the chance for true componentization of software.. "Don't need Word, here's simple edit for free - oh, you need a spell checker, you can get this 50,000 word one for $5 or this super-fancy one with grammar checker one for $10, click here to try it free." Building and promoting a better mousetrap would no longer be a daunting task, because you can do just one thing better, without having to replace (and sell) all of Office to do it. I hope so, because I think an army of 'little guys' can far, far better represent the diverse user base than a handful of 'big guys' <Ramble off> Ken Actually, not only does it make sense, it'd be a great thing. These OSes are inherently unable to run a good text-based shell, they just usually don't. XMLTerm makes perfect sense on Mac and Win. Don't think of it as a local command shell, think of it as Mozilla's built-in handler for telnet:// URIs. nothing really says what the back end to this is - i.e. what are you typing into? for the screenshots it is obviously a shell, but how is the interaction carried out. it must be going over some protocol like telnet, or is he prodding a pty? or even ssh? Some quick responses to comments on XMLTerm: 1. Agreed the graphical "ls" looks kind of weird. Most command line users, myself included, wouldn't use it simply because it takes up too much screen space. It is just an example and not actually a part of XMLTerm. As a long time command line user, I'm not even sure I like the blue/black color combination. But I couldn't thing of a better way to distinguish between plain and hyperlinked text ... It is trivial to get the "cat my.tiff" command working under XMLTerm and maybe it would make a better example for the next version. 2. Regarding the Mozilla-specific nature of XMLTerm: I have taken the trouble to code the core portion of XMLTerm to be completely independent of any browser. It is actually written in plain C and is dually licensed under GPL and MPL. I was aware of only one open source layout engine that was powerful enough for what I wanted to do, and so I decided to build a Mozilla-specific layer on top of the core XMLTerm. If Gnome comes up with a good GPL'ed layout engine, for example, the core of XMLTerm could be made to work with it. 3. About XMLTerm and Windows: Strangely enough, I actually use the Bourne shell (as part of the Cygwin utilities) and the TC-shell for locating, moving, or renaming a bunch of files under Windows, with features like command line completion etc. I find the Windows GUI or the MSDOS shell too slow for those operations. Eventually, I hope to get XMLTerm working under Windows so that I can use these shells in a fancier window, but it is not high on the list of priorities. I am out of touch with the Mac world, but I don't suppose it has shell scripting. 4. About the back-end: At the moment, XMLTerm is configured to use a pseudo-TTY on Linux and Solaris. It has a fallback option of using cross-platform NSPR pipes to communicate with the client process on other platforms where PTY support has not been implemented. Saravanan First I must say I'm very impressed, with this. My CLI experience is limited to DOS and some vanilla Solaris boxes but this has the features I want to make the command line really efficient. As someone learning Applescript right now I believe it and Apple Events could be used for Mac shell scripting. Know there was a now-outdated app C.L.I.max than acted as a CLI for the Mac. Anyone with knowledge about how Apple Events/Script work able to add more about how this could be done. Brian "What was my login again?" Hmm.. gotta add SSH support ;) this would be perfect for a kiosk at the airport or something, i think. Sort of reminds me of the RIPScrip and NAPLPS graphical terminal standards from way back in the BBS days. I remember just when RIP-enabled telnet content started becoming available, the web came along and took over everything. I remember walking to school and back two miles uphill both ways. Seriously, this is cool. Programming stateless web applications is getting really old. Mozilla seems to be tapping the creative juices of outside developers already in it's pre unstable beta stages. COOL! As far as java, the operating system, what should and shouldn't be etc . . Who cares? Let the chips fall where they may. I personally smell a revolution brewing. Seems like there will be some grinding and gnashing of teeth for the millennium after all! Can't wait! I love this idea. I think a good application for XMLTerm would be MH. MH is already a set of small applications. "Pagelets" could be written for each of the pieces. At some point I could stop spawning netscape windows to view everyone's lousy HTML mail. rob nothing really says what the back end to this is - i.e. what are you typing into? for the screenshots it is obviously a shell, but how is the interaction carried out. it must be going over some protocol like telnet, or is he prodding a pty? or even ssh? sick, really sick First off I'd like to say that this is a GREAT idea! I was thinking along vaguely similar lines myself, although I'd only got to the point of 'wouldn't it be great to have a mozilla-based terminal emulator', and I certainly hadn't thought of the possibilities of allowing full html/xml in the terminal window. It's an *awesome* concept! Two questions occur to me about XMLTerm (future) features... one looking backward, one looking forward. First off, do you plan to make it completely backward compatible, to the extent of being able to run applications which make heavy use of cursor positioning (examples include vi, pine, emacs without x, and so on) and support ANSI colors as well as XML colors? Secondly, supposing XMLTerm is being used as a telnet client, so the application writing to the terminal is on a separate machine than the terminal itself. Is it possible for images to be sent along the same stream as the regular text data, or does the app have to simply point to a URL? In other words, would commands like lx -i work remotely even if the local machine doesn't have copies of the icons? Again, GREAT idea! Stuart (wishing that lack of membership didn't make you "anonymous") Future features: 1. Full screen implementation: The hooks are all in place. All that remains is the tedious task of coding each XTERM escape sequence. A <PRE> HTML element will be used to display the full screen. It may turn out to be slow, but hopefully not. 2. Any valid HTML fragment may be transmitted by the telnet client. I used a file:// URL in my example, but it is perfectly OK to use a http://remote_directory/icon.gif URL. So lx -i will work on a remote client. (I don't think the HTML allows raw images themselves to be transmitted) Saravanan Interesting thought...obviously wouldn't be feasible for a while... I could forsee having an XMLTerm entry in termcap/terminfo...then all the escape sequence->XML could be handled for you by the termcap/terminfo lib. Obviously, it would take a while for something like that to be distributed far and wide enough to actually make it useable, but it may be something that should be worked towards. Jeff ??? Am i the only one to notice that Mozilla actually becomes the next generation of Emacs? XMLTerm is such a great development. This shows both the strength and one of the problems of Mozilla. XUL allows very powerful applications to be built with the DOM and JavaScript, but certain underlying features which are outside of JavaScript need to be put into XPCOM components. In XMLTerm these XPCOM components are written in C, but imagine if you could write these components in Java? I know that there is work going on to write the components in JavaScript, but Java has such amazing networking powers. If XMLTerm's XPCOM components were in Java the program could be distributed across any computer that had a JVM and Mozilla. We should avoid extending JavaScript into having as many support libraries as Java currently has, and just use it as a scripting glue language to link existing XPCOM components together into an application. I'd love to see someone convert XMLTerms C XPCOM components into Java ones when the Blackwood project moves ahead! Thanks, Brad Neuberg |