Slashdot Mirror
Creating Applications with Mozilla
On the first and most obvious level, the book is just the typical, thorough treatment of the important APIs that we've come to expect from O'Reilly. There are chapters addressing all of the important layers of the Mozilla platform and plenty of examples that show you how to customize the platform. Some may want to change the icons and others may want to add more robust features. The range of possibilities is surprising and coders are creating one-to-one communications enhancements, add-on widgets, and even games. There are certainly some things missing, and some areas that could use more detail or more complicated examples, but the book is already 454 pages long.
On another level, this book is also one of the first finished documents that explains what the Mozilla group has really been up to for the past five years. Some have abandoned the project, and others have attacked it as fundamentally misguided. This book shows why it took so long by demonstrating all of the cool features added during the long march to a new, thoroughly extensible architecture.
Are the results enough to justify the time and the effort? Some note that the features may be a bit overhyped, because building your own browser with the Mozilla API is like making a pizza with $15 and a telephone. While there's a large part of the book devoted to the work you can do to change the look and feel of the buttons on your browser, the book and the project offer much more. The Mozilla project is one of the biggest threats to simple tools like Visual Basic to come down the pike in some time. The various layers offer many ways to provide good, customizable interfaces to databases, the web, and much more. I can see how many corporate development shops may want to start making Mozilla the platform for a license-free front-end, simply because it's a straightforward tool without extra costs or restrictions.
At the most abstract level, the book is a great way to get a taste of modern software development. Computer scientists sometimes fix problems by adding more and more layers of indirection. This may not solve anything, but at least there are hooks for a real solution to use some time in the future if some one ever does figure out how to make the box do it. The Mozilla browser is one of the most extreme examples of this philosophy to ever emerge. Emacs was something special, but this is even more insane. Everything can be changed around by rewriting some XML and Javascript and most people don't need to juggle the pointers in grubby C to do amazing things. I realize it's not as beautiful as Lisp to some, but it's got a clarity and level of abstraction that's stunning to behold. Lisp was just procedural, while XML is more like logic programming.
This relentless customizability embodies one of the deepest reasons for the success of open source. Technology is inherently complicated and the only way we can use it is if we can look under the hood. You can say all you want about CVS trees and bazaars filled with competing code, but opening up the interface is one of the most powerful themes of open source. It's not about teaching people to build their own VCR or PVR from scratch, getting the VCRs for free or even debugging the VCR's source code -- it's just about making them easy enough to program.
The book illustrates how Mozilla opens up the API to create a relatively easy language for people to use. The real open source is not the C in the tar ball, but the XML interface spelled out in the book. Many people feel that the most important thing that the first browser designers did was make it easy for people to see the HTML tags marking up the document in front of them. The new Mozilla takes this transparency to a new high.
If you look at the book at all of these levels, you can see that this is one of the most important documents to emerge from the open source community in some time. At first glance, it's just another set of APIs for us to wiggle. I realize it's not fair to credit the Mozilla team or the book authors with creating the browser or XML ex nihilio -- they just jumped on some of the most popular bitwagons propagating across the Net. But the result is a stunning completion of a very important and cohesive vision. The book doesn't crackle with bleeding-edge novelty, but shines with the certainty of a job well-done.
Peter Wayner is the author of Translucent Databases , Disappearing Cryptography , and a number of other books. You can purchase Creating Applications with Mozilla from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Mozilla just becomes a toolkit and VM to run applications. Think of it like Java. Can you run a java app w/o the JVM? No. It's not executable without it.
It seems Mozilla is working closer and closer to being an OS than just a browser. Kinda funny if you think about it, where MS has windows which was supposed to be an OS and is now including a browser.
-
ping -f 255.255.255.255 # if only
Ugg you got modded insightful. I better clarify before I get modded down:
This article is about the mozilla application framework. The application can be a stand alone application! This is not some kind of "mozilla only webpage."! This is just a method for creating an application that uses parts of the mozilla codebase, or more appropriately (though you and the mdos don't seem to understand the meaning of this) the mozilla application framework.
--
WHO ATE MY BREAKFAST PANTS?
I know this is short notice, but I'm going for dinner with one of the the authors tonight in two hours time, and then going to his talk with the Internet Society in Trinity College Dublin (Ireland). The details of the talk are here.
The TCP/IP effort was very focused on standards and interoperability. That's what the U.S. Department of Defense, which funded the effort, wanted, because they wanted all their computers to be able to talk to each other. (Back then, IBM, DEC, Xerox, etc. each had their own network protocols, all incompatible.) The DoD project management people were very insistent on this; a formal DoD TCP/IP standard was pushed through. The individual implementations were forced to comply. (The Berkeley BSD crowd had to be hammered on a bit; they'd gone off on a LAN-only tangent for a while, neglecting long-haul issues.) And it worked.
C was the creation of two people. K&R C was rather PDP-11 oriented and lacked a real type system, but UNIX took off within the academic community before C was standardized. ANSI C came years later, so the UNIX world was still on K&R C years after the DOS world used ANSI C. Eventually, everybody settled down on ANSI C, but it took a while.
The book is good and interesting, but it reminds me another book, Programming Jabber: a lot of examples in the book, and no available examples in real life (besides Jabberd itself).
Less is more !
I think you are so seeing the potential. What *is* needed is an HTTP-based "GUI Browser". HTML-based browsers don't cut it. If Mozilla can fill this need, great.
Where the contention comes about is in how fat the client should be. IMO, most or all the functionality should be on the server, with the browser being Turing-dumb. (I drafted an XML protocol called SCGUI to do just this.)
However, some people and applications are going to want/need client-side scripting. If it gets to be too much client-side scripting, then you have essentially created a client-server application. That is probably what Mozilla should *not* target.
I guess what I am trying to say is that there is a need that Mozilla can fill and that I hope it does not get carried away in an Emacs-ish way.
That niche is an HTTP-friendly GUI browser with *optional* scripting capability to have *some* local Turing-complete application programmability sprinkled in. IOW, get right what HTTP+DOM+JavaScript could not get right.
But, if they make it a fat-client client-server tool, then slap them with a wet Visual Basic box.
Table-ized A.I.
I've read several chapters of this book and I'm trying my hand at Mozilla app development. I'm mainly interested in it for "better" web applications. HTML was never designed for that kind of thing, and I'm frankly tired of it being used for such. Mozilla+XUL can make applications that load like web pages but whose interface is more like traditional desktop applications. Rock on!
I really DO believe that Mozilla has a bright future in this regard. It provides some great tools. I about wet myself when I discovered the Javascript Debugger! As the article says, it will provide a totally free/Free way to deploy custom applications.
It's also a potent tool against IE's monopoly. If there's one thing that can cause people to switch from IE to Mozilla, it's applications that only work in Mozilla! I used to support the "Best Viewed with Any Browser" campaign (which is still appropriate for pure information) but I have since realized that because Mozilla is Free, open, and cross-platform, there is no need for anything else! I now encourage people to develop web-based applications in XUL.
I do have a few small gripes with it. Textboxes don't wrap like they do with HTML's "wrap=soft" attribute. That's bad. I asked in a newsgroup and was told that this functionality would be in Mozilla 1.2.
Also I was hoping to embed an HTML editor in my application, so that people could post HTML in their comments and have a fancy editor for them. To my dismay, it appears like the HTML Composer can ONLY be embedded in local chrome:// apps, not in those served by HTTP. Anyone know a way around this?
Overall though, Mozilla kicks arse! I think it has a very bright future!