Forgot your password?
typodupeerror
Mozilla Books Media The Internet Book Reviews

Creating Applications with Mozilla 255

Posted by timothy
from the lizard-is-the-new-black dept.
Peter Wayner writes "The book Creating Applications with Mozilla did not set out to capture the essence of modern open source software development in a few hundred pages, but it comes closer to that unreachable goal than almost any other book I can imagine. Everything is there: the proliferation of acronyms, the funky names, the endless layers, the earnest collaboration, the unstoppable yearning for customizability, and, of course, plenty of source code. The book is just supposed to be teaching us how to turn Mozilla into a front end for everything, but it's really a distilled exhibit of all that is hip and now in code creation." Peter's review continues below.
Creating Applications with Mozilla
author David Boswell, Brian King, Ian Oeschger, Pete Collins & Eric Murphy
pages 454
publisher O'Reilly
rating 9
reviewer Peter Wayner
ISBN 0596000529
summary How to use the Mozilla APIs to do anything.

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.

This discussion has been archived. No new comments can be posted.

Creating Applications with Mozilla

Comments Filter:
  • from what i've read in the past it sounds like mozilla can be used to develop just about anything. is this true? who has done it? what about applications? it's odd to think of a browser as a platform for application development. i'd really like to get my hands on a good explanation. perhaps this book.
    • IIRC someone was creating a complete desktop enviroment with mozilla, but i don't remember the name. It was mentioned some while ago here on slashdot.
    • by Hugh Kir (162782) on Wednesday October 16, 2002 @10:48AM (#4461691)
      I've been developing some apps using Mozilla at work. I've been really happy with it, frankly. The GUI development couldn't be easier, you can create relatively complex widgets with it easily, and, with the exception of any compiled XPCOM objects you may have, it's cross-platform. We picked up a copy of this book as well, and it's quite good. I don't know if it's the wave of the future or not yet, but I rather hope so, because it would make my life a lot easier (especially when I have to write Windows apps; I'm not a big fan of the complex IDE tools Microsoft provides).
      • I've been developing some apps using Mozilla at work. I've been really happy with it, frankly. The GUI development couldn't be easier, you can create relatively complex widgets with it easily, and, with the exception of any compiled XPCOM objects you may have, it's cross-platform.

        Do you do any database access with it? Are there Native 'Mozilla' database modules, or do you use ODBC?

        • by rycamor (194164) on Thursday October 17, 2002 @01:34AM (#4467001)
          For remote access, all the server has to do is send XML data to Mozilla. Also, Mozilla natively supports the SOAP API [oreillynet.com], so it can access any SOAP data source. Cool, huh?

          It's a little different if you are talking about accessing client-side data sources. Mozilla/XUL is (kind of) a virtual machine (VM), meaning it doesn't intrude too much upon the client's OS. But, XUL/XPCOM has bindings for all kinds of programming languages, such as C, C++, Perl, Python, Ruby, and the list keeps getting longer (Good intro here [ibm.com]). Thus, on the client-side you can use the database capability of any of these to talk to the Mozilla elements. I'm sure it wouldn't be too hard to whip up just a little communication between Mozilla and ODBC ;-).
    • by Micah (278) on Wednesday October 16, 2002 @04:17PM (#4464147) Homepage Journal
      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!
  • by PhysicsScholar (617526) on Wednesday October 16, 2002 @10:40AM (#4461615) Homepage Journal
    This is one way in which you just know that the Mozilla developers are at the top of their field(s) -- deciding to go with XML full-fledged (several years ago, too) was one of the greatest decisions they've made so far. The XUL interface, which is basically XML-based at its core, is about as flexible as one can get with the UI experience.

    Furthermore, and of particular interest to someone like myself, the XML format offers a number of advantages for computational physics: clear markup of input data and results, standardized data formats, and easier exchange and archival stability of data.

    I will definitely use a few dollars of grant money to purchase this book and keep it in the labs for all to read and enjoy.
    • by Tablizer (95088)
      The XUL interface, which is basically XML-based at its core, is about as flexible as one can get with the UI experience.

      When I last checked, XUL did not have coordinate-based positioning, but rather nested-based. Coordinate-based works better with visual screen builders IMO. True, it does not auto-scale as well, but when the boss wants something very specific WRT GUI layout, coordinates are much easier than nesting to give him/her precisely what they want.
  • the important part (Score:2, Insightful)

    by cetan (61150)
    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.

    To me this is the one of the most important parts. I'm not a programmer, nor will I ever be I think. But from an evangelism perspective, I can point to this and say: "See, see? They were not just f-ing around for years, they were building something with amazing functionality!"
    • by K. (10774)
      The last thing the world needs is non-programmers evangelising programming tools.
    • To me this is the one of the most important parts. I'm not a programmer, nor will I ever be I think.

      But have you dabbled with web design? If the answer is yes, then you can write Mozilla apps. It's due to this fact that it's so easy to write patches for Mozilla. XUL (which if you know html is easy), CSS and JavaScript are all you need to know.

      You could well be a programmer with Mozilla, and never know what a pointer is.

  • by Anonymous Coward on Wednesday October 16, 2002 @10:41AM (#4461628)
    How come Lisp become 'just procedural'?! Do u have any idea baout what u r writing?
  • Online book (Score:5, Informative)

    by redtail1 (603986) on Wednesday October 16, 2002 @10:47AM (#4461675)
    In true open source fashion, the book is also available in online form at http://books.mozdev.org/chapters/ [mozdev.org]
    • by Tablizer (95088)
      In true open source fashion, the book is also available in online form

      And in true open source fashion, it is about to be slashdotted also.

      Viva Traditions!
    • Yes, it's available for browsing online,
      but not in a single downloadable package.
      It's published under the Open Documentation License.
      I'm going to have to create a single .tgz for the book.
  • by Jack Wagner (444727) on Wednesday October 16, 2002 @10:48AM (#4461680) Homepage Journal
    Isn't so much about standards, it's more about de-facto standards and their general tendancy to change. I couldn't see devoting 5 or 6 months to develop a custom application specifically for Gnu/Mozilla when one year down the road they may decide to alter the XUL "standard" and totally screw me.

    This is why stuff like TCP/IP and "C" took off, because they were in the hands of a standards body who were responsible and considerate of issues like this.

    The Gnu/Open Source community needs to take into consideration that since they are working their way into the mainstream they *must* begin to be more proffesional and intelligent in matters of "standards" or they risk alianating the commercial development community.

    That would be a serious mistake on their end, serious indeed.

    Warmest regards,
    --Jack
    • by Animats (122034) on Wednesday October 16, 2002 @11:07AM (#4461810) Homepage
      That's true of TCP/IP, but not of C.

      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.

    • Indeed (Score:3, Interesting)

      by Jon Erikson (198204)
      As an IT consultant I've pushed this point to many of my clients before; either you go for a solution supported by robust standards supported by accredited standards bodies, or you go for a de facto standard which while it may not have the cast-iron guarantees that say an ECMA-approved standard would, at least ensures that you're not going to get left behind your competitors.

      For a group of people which rely on so many open standards (and indeed, complain when companies don't use them!) I've yet to see little progress here on ensuring XUL remains an open standard. Which is a pity, because otherwise it has little to recommend it, no matter how extensible it is.

      Also, does anyone here know anything about performance issues? Visual Basic nowadays is fairly reasonable for certain aspects of enterprise solutions, but if this is anything like Mozilla I'm not sure I could recommend it as being a good platform for applications.

    • by IamTheRealMike (537420) <mike@plan99.net> on Wednesday October 16, 2002 @11:19AM (#4461899) Homepage
      XUL is largely frozen, and if you only use the 1.0.x branch, it's guaranteed to only get perf improvements and bug fixes.

      Having said that, 99% of XUL is now solid anyway. If you develop apps, the syntax may change or more likely you'll get new features, but if you then want to upgrade to that version of Mozilla, you can simply run the old XUL through some XSL transforms. It's the same as with any API really, except it's easier to upgrade/alter XUL.

    • This is a ludicrous statement (not least for calling it Gnu/Mozilla).


      How are they screwing you exactly? Is it because you get millions of lines of source code to an entire application development environment and an extremely generous licence terms for free? Or is it that you're not happy that XUL is not standardized by some body such as w3c?


      If the latter is your worry, simply don't upgrade and XUL will remain forever frozen in the state that you released your app in. Alternatively take the risk and download a new version of Mozilla in six months and see what minor tweaks you need to keep it working and benefit from all the bug fixes that six months of open source development bring. Besides, the XUL specification is already documented and versioned, so there should be no worries about it suddenly changing, at least in the forseeable future.

    • How can you say that "standards" are what lead to wide-spread adoption? The IBM PC was a defacto standard that was mutated through a thousand little and large vendors who changed it over time. It maintained its dominance mostly because the market deeply wanted a cheap, flexible option, and was not unduly bothered by the constant shifing standards (XT->IDE->ATA/xxx->?, ISA->EISA->VESA->PCI->AGP, etc, competing video "standards" that weren't, etc, etc).

      Same goes for Windows. Here's an example of a locked-in proprietary solution. You'd think that they could remain internally consistant, but APIs change radically every release. You go from one widdget API to another. Support is dropped at odd times. DDE becomes COM becomes COM+ (nothing like COM, of course) becomes .Net, etc.

      Now you pan over to protocols. Have you tried to code against SSL only to have to re-code because now the target you want to talk to is SSL3, and your code no longer works? Have you tried talking to SMB only to have Microsoft add in another spin?

      These are all widely adopted de-facto or even well organized standards. They change. They break backward compatibility from time to time. This is software (and in some cases, hardware). Cope.
  • online version (Score:2, Redundant)

    by alexc (37361)
    here is the online version of the
    book [mozdev.org]
  • IWBEvent (Score:2, Funny)


    I implemented IWBEvent for my app which uses the MSHTML control. There is a bug in IE which causes the OnUIActivate method to be called with an incorrect parameter.

    Does Mozilla have an option to simulate this bug so that my app can be run without change on that platform?
  • by Tayto (4193) on Wednesday October 16, 2002 @11:05AM (#4461800) Homepage
    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 [netsoc.tcd.ie] in Trinity College Dublin [www.tcd.ie] (Ireland). The details of the talk are here [netsoc.tcd.ie].
    • 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 [netsoc.tcd.ie] in Trinity College Dublin [www.tcd.ie] (Ireland)

      You will be having dinner in Ireland near a college?

      I don't think you guys are going to be sober enough to deal with too much tech details tonight.
  • by K. (10774) on Wednesday October 16, 2002 @11:16AM (#4461872) Homepage Journal
    Anyone planning to go to this probably knows already, but Brian King is giving a talk on Mozilla in Trinity College Dublin tonight. More details at http://netsoc.tcd.ie/events/0203/mozilla.php [netsoc.tcd.ie]
  • by oldstrat (87076) on Wednesday October 16, 2002 @11:20AM (#4461904) Journal
    Well the subject of my comment pretty much gives away the comment.

    ActiveState http://www.activestate.com (The Perl,Python,PHP,Tcl people) have a great IDE application written on the Mozilla engine called Komodo, it's up to version 2 now and certainly worth checking out.

    Now if only ActiveState would just open source it, after all it's base is open.
    • I have to agree. I tried the 1.0 version way back, and it really, really, really sucked. But after a recommendation recently, I've tried out 2.0 on windows and 1.2 on linux (2.0 on the way)... and:

      I can sum up my review of it like this: I'm buying it the minute the paycheck comes this month.
  • XUL (Score:3, Informative)

    by hpavc (129350) on Wednesday October 16, 2002 @11:22AM (#4461929)
    i have to say that i have converted a bunch of cgi's that deliver HTML to cgis that deliver XUL and provide RDFs. the interface is awesome ... so many things you cannot do with IE alone (unless you cookup some ActiveX)

    it was rough in the begining since i had people that were not using mozilla and even now some people just use mozilla because they have to.

    but the power of the lists, tabs, etc are awesome compared to having to write javascript/layers/etc crap that takes more effort than the cgi environment to code.

    i love it ... i hope an activex control for IE is around that will allow IE to use XUL
    • i love it ... i hope an activex control for IE is around that will allow IE to use XUL

      There is an ActiveX control that emulates the IE APIs allowing a drop in replacement of Trident (the ie rendering engine) with Gecko. In theory I guess some registry hacks could make IE itself use Mozilla, in much the same way that Konqueror can be flipped between KHTML and Gecko. Dunno if anybody has done that yet, but for embedding apps there is already a solution.

  • by Tayto (4193)

    One of the big updates being done for embedding purposes in the big 1.2 push is to get a basic installation prepared which can be used for all sorts of Gecko/Mozilla-based applications. See it coming to an application near you soon!

    This is a very important development as it means that the full Mozilla suite will no longer need to be packaged with your custom application. The basic installation may even be installed on the system already - and can then be discovered and used by your system without installing a second copy!

    This miraculous beast is the GRE, and its webpage is here [mozilla.org].

  • by Fished (574624) <amphigory@gmaCOMMAil.com minus punct> on Wednesday October 16, 2002 @11:33AM (#4462033)
    This is not just making fancy web pages. This is not about the Mozilla browser, it's about the Mozilla framework. This framework was used to develop the browser, the mail program, composer, and everything else including chatzilla. These run as local applications on your box, just like Mozilla composer does.

    There are a couple of very interesting examples developed using this technology out already:

    • OEOne [oeone.com], a complete desktop environment.
    • Kimodo [activestate.com], a python and perl IDE.
    I myself am working on a Bible program that will run, locally, under Mozilla. This is probably the future of desktop application development for most stuff.
  • $24.50 [bookpool.com] plus shipping, as of 16 October, 2002
  • Mozilla Development (Score:5, Informative)

    by Lao-Tzu (12740) on Wednesday October 16, 2002 @11:55AM (#4462211) Homepage

    I've been developing a Mozilla-based application component since August 2001. It's an HTML-rendering MOO client [www.moo.ca], and recently I've been pouring some 90% of my free time into working on it.

    75% of that 90% of my free time lately has been updating the application to newer standards which have come into place since August 2001. For example, the Navigator/Mail/Editor/Chatzilla options used to be on the 'Tasks' menu in Mozilla, and were moved to the 'Window' menu around 1.0rc1. Bang, suddenly my application stops working properly, and less importantly, stops being a friendly component which works like all the others. A patch from a friend moved just about everything over to the 1.0rc1 way of doing things, and all was fine. Not everything worked flawlessly, though. The 'MOO Client' menu option didn't have an associated key visible, and the 'Window' menu inside MOOzilla didn't have any visible keys. The menus inside the application had long since stopped graying-out/disabling properly depending on what you have selected in the window. Many hours of last weekend was spent fixing these problems by conforming to new command handler expectations, and so on. (Where 'new' means 'changed since 0.9.6'. ;))

    XUL is a wonderful tool. However, it runs dog slow on OS X. You don't have to take my word for it, just look at the Pheonix project. Pheonix is available for Windows and Linux, but not for OS X. Why? Because Chimera exists for OS X, which is faster (I'm using it right now) and integrates with the OS better. But... it doesn't support XUL. That's why it's faster. So where is my Mozilla application left? Stuck in the massive Mozilla suite when it's run in OS X. Mozilla, at startup, uses over 120 megs of RAM on my TiBook. Thank God for good VMs.

    When initially writting MOOzilla, the XUL documentation was shit. The only place to go for any idea of how things really worked was deep inside the Mozilla source. And sure enough, this worked. The official XUL documentation at that time had sections which trailed off in 'blah blah blah' often because someone got bored of writting. I specifically remember it once read 'This is very important because blah blah blah'. Arrrg! How frustrating!

    Mozilla is a powerful application development environment. XUL is a wonderful tool. Books like this one are going to make the world a better place for Mozilla component developers. And more cross-platform software developed with Mozilla makes the world a better place for users. Now... if only we can somehow apply this book heavily to the head of people who don't want to download Mozilla to try out an application, because they don't want to use it as a web browser. *sigh*.

    • by ttfkam (37064)
      ...and the fact that Chimera doesn't have all of the features of Mozilla has *nothing* to do with it.

      By the way, where were you when the Moz developers were saying that 1.0 was supposed to be the stable API to work on? I applaud you for developing on Moz, but to state that you had no warning about an API changing from under you is foolish. I'm sorry for your pain, but you knew that you were holding a hot poker.
  • Crap! No better yet, DOUBLE CRAP! Has the entire concept of higher level programming languages been lost?! WTF people we have to stop the mad-people (madman is not PC apprently) from screwing up the whole concept of high level language.

    High Level Language is to make it easier and quicker to code. Remember doing "Hello World" in ASM? Then compared to when you wrote it in C? Where did that innovation go? I remember having to code 300 to a 1000 lines to accomplish what I was able to do in 10 lines in C. Also complexity was reduced in high level languages. Where did that mindset vanish.

    Now I have some yahoo trying to tell me to use Mozilla as a front end to programs? Does using Mozilla some how make life easier for me? Quicker development times? Less errors? Let me think

    NN NN OOOOOOOO !!
    NNNN NN OO OO !!
    NN NN NN OO OO !!
    NN NNNN OO OO
    NN NNN OOOOOOOO !!

    So once again we have another programming FAD! Aww crap can I just get a good programming language...
    • by Tablizer (95088) on Wednesday October 16, 2002 @01:06PM (#4462775) Homepage Journal
      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.
      • Have you noticed that we are going backwards to Mainframe-like computing? Wow! Could you imagine if they had it right the first time!
  • by LoRider (16327) on Wednesday October 16, 2002 @12:15PM (#4462381) Homepage Journal
    But is the book any good. All I got from the "review" was that the reviewer thinks Mozilla is cool. What about the book? Was the book good? Was it well written? What did the reviewer like about the book, not the subject, that warrants a 9? Why not a 10, what didn't he like about the book?
  • by axxackall (579006) on Wednesday October 16, 2002 @01:03PM (#4462752) Homepage Journal
    I wonder if it's possible to create database clients similar to MS Access based on Mozilla/Gecko/XPCOM code. And if the answer is positive then why I can not find anything like that?

    The book is good and interesting, but it reminds me another book, Programming Jabber [oreilly.com]: a lot of examples in the book, and no available examples in real life (besides Jabberd itself).

  • I run Komodo, so I know you can build on the Mozilla base, but other than the miriad of browser variations built on it, just what the heck can you do? If I were to replace some Perl/Tk stuff I wrote (simple filing tools, that kind of stuff, on Windows) would I be able to build it all on Mozilla? Anyone care to describe some applications that developing under Mozilla would be relevant for?
  • I can get plenty of opinions about XUL by looking through previous Mozilla /. posts. I just want to know if I should buy the book. Do they have a tutorial and step us through a FOO test application? If so, what is the application? What other tools do I need to create the application?

  • by Dalroth (85450) on Wednesday October 16, 2002 @02:29PM (#4463389) Homepage Journal
    This isn't even close to a book review. He does nothing but glower over how great Mozilla is (which we all agree on), but says nothing about the quality or content of the actual book.

    The book itself *IS* good (at least that which I have read so far). You'd never be able to tell from this review though....
  • Data based GUI (Score:3, Interesting)

    by samwhite_y (557562) <`moc.oohay' `ta' `spwerci'> on Wednesday October 16, 2002 @02:31PM (#4463403)
    I have been wondering when the first truly "data driven" solution would be created for standard heavy client GUIs. HTML created a standardized approach to simple "Info" presentation (and submittal) GUIs. Even though the primary goal for HTML was quite limited, this idea of having a "data" driven solution to info presentation has been such a hit that it has generated huge and powerful scripting solutions all devoted to enhancing this one simple GUI idea. It seems obvious to me that almost all facets of an application should be data driven in a similar way, including all GUI presentation in heavy weight applications. In a truly modern application environment, all code that determines placement of GUI elements and the simple logic that binds them together should be done in an HTML style environment (or its cousin XML). This data driven approach should be so pervasive that much of the higher-level logic of an application should be in data and script.

    I laud Mozilla for going down this road and it is clear to me that the core developers for Mozilla are a step above your standard programmer. Some accuse Mozilla for not following a method that would create "standards" for their XML GUI description language, but I have found that the successful "standards" usually follow already adopted and reasonably mature technologies. You do not know how you want to design something until you have done it, used it, and given it to other people to play with. Only after an application has grown sufficiently to include all the thousands of unexpected details is it sufficiently mature for people to talk about standards. For example, I consider the EJB specification's largest failing is that they tried to standardize it before it was actively used for a couple of years. Only now that we have some mature app servers do we really have an idea what needs to be in the core EJB specification. If EJB had followed this road, maybe application developers would not need to use vendor specific code for the critical parts of the functionality. Like OO, the mantra of "standards" seems to be more of a marketing tool to get Fortune 500 companies to cough up millions of dollars than something that really influences how sophisticated and successful applications get developed.

    I have my own questions for the Mozilla team. How do you deploy "overrides" of existing configurations. Suppose I want to deploy a "batch" of changes that I want to turn on or off. Is there a way to create configuration "layerings" in XML files so a group of data specifications can be conditionally included from a set of external files? How much scripting is allowed in these files? If I want to write conditional code for specifying a color (such as a color choice per day of the week), is there a way to write scripting solutions for that need? Of course, I could read the book but I am lazy and I suspect that it would not give a full answer.

  • by Lucas Membrane (524640) on Wednesday October 16, 2002 @03:42PM (#4463925)
    ... is to be able to develop an app once, then sell it as single-user standalone, or multi-user with browser-like interface to run on the customer's server, or rent it as a web app on the developer's server, or rent it as a web service on the developer's server -- while maintaining one set of code, not four.

    How close is this Mozilla thing to supporting that?

  • by rice_burners_suck (243660) on Thursday October 17, 2002 @03:17AM (#4467379)
    What I don't get about Netscape and its developers is... Why do you folks think that the browser must be the front end to everything? Why shouldn't, for example, a text editor, or email client be the front end to everything? As far as I am concerned, the operating system has evolved to be this front end that everyone is looking for. Back in the day, the operating system did mundane, boring things that users didn't want to think about. But now, the operating system is expected to do everything, plus make cappuccino. So why do we need yet another (entirely too bloated) layer--the web browser--on top of the operating system? A web browser should do just that: Browse the web. Email should happen in a separate program. News in a separate program too. IRC or whatever in yet another separate program... The fact that web browsers need to provide the ability to interact with web pages doesn't necessarily mean that the entire world must work over HTTP port 80. Because there are 65534 more perfectly good ports to work with, and for a good reason.

    I would like to relate a recent experience with NETSCAPE 7.0. Please excuse two paragraphs or so of background information...

    Those who have read my literature (/. postings) in the past will know that I HATE Windows because it is TRASH. But unfortunately, my mother's work requires her to use Windows due to a proprietary application they use that isn't available on an operating system that actually works. So she has this laptop with Windows XP Home Edition. Now I'll admit that for the rare cases that I must use Windows, there's a crappy old box around here that's running Windows 98 SE. It's pretty crappy, but I removed pretty much all the superfluous junk from the installation, so it doesn't crash more than once in a blue moon^H^H^H^Hscreen or so. So while 98 is not my operating system of choice, it's admittedly not quite THAT bad when there's no other way to get the job done. I've had very minimal experience with setting things up for people on 95, 98, Me, NT, and 2000. All of them were crap. 95b was the best one (it could run for up to six or seven days without a reboot), but doesn't run on new hardware. 98 SE is somewhat usable. Me was probably the worst one I had seen so far... Everything is so complicated, cluttered up, and messy. But then my mother asked me to "make the internet work" on her laptop... And it's running XP.

    Now I do have to admit that I was impressed with ONE aspect of Windows XP: You plug in a network cable; it recognizes it and you're on the network. You plug in a ZIP drive, it recognizes it and that's that. You plug in a printer, it's automatically added to your printers thing. I wish somebody'd reverse engineer that and make it work on operating systems. But that was the extent of my good impression. The rest of XP is GARBAGE!!! The multiuser aspect of it is really clunky and crappy. The graphics are REALLY ugly; I had to revert it to the "Classic" look before my vision got damaged. The sounds were as stupid as ever; I had to delete them all. And the thing was as unreliable as software from Microsoft. Oh wait... That
    is from Microsoft. Guess that explains it. :)

    But I digress... So back to *N*E*T*S*C*A*P*E* I installed Netscape for my mom, because Internet Explorer is trash. Netscape, in my opinion, is lacking in many areas (such as usability), but I'll classify it as software, rather than trash. So I installed it. The install went along pretty smoothly and before I knew it, I had Netscape launched. The new graphics are MUCH nicer than the extremely crappy ones in Communicator 4.x. But the initial screen was SOOOOOO cluttered!!! Buttons and tabs and side bars EVERYWHERE! As an experienced user of computers and web browsers, I couldn't hear myself think, so to speak, in all this optical noise. I immediately turned all that crap off and modified all the settings to my liking, so that my mother, who has much less experience than myself, would actually be able to use the damn thing. And then it happened. The next time I launched Netscape, everything locked up and the disk started crunching and grinding away like there was no tomorrow. Even the ctrl-alt-delete window took forever to show up. I ended up forcefully shutting off the power, because I couldn't even log out. (Yeah yeah... File a bug report--but do you HONESTLY think that my mother knows what a bug report IS, let alone knows how to file one?!!) And this is where the background information on XP comes in... I guess it REMEMBERS what made it crash and when you reboot it (or log out and log back in) it does it over again, consequently putting itself in the same situation and locking up again. That's what happened. Whenever I logged into my mother's account, the whole computer became so unresponsive (from the grinding and whatnot) that I couldn't even open up the huge, cumbersome Start menu. (Mafiasoft. Where do you want to pay today?)

    I noticed that the other account, that I had originally set up for her out of the mere habit of always giving myself three or four accounts on my BSD boxen, still worked fine, so I logged into it, created yet another new account, moved all her files over, and deleted her original account. Oh yeah, and I removed Netscape and purchased a copy of the newest Opera 6.x for her. Sure, its initial screen is a bit cluttered and I have a few complaints about the increasing complexity and proliferation of seemingly unnecessary features (that other people probably want, just not me), but it's small, fast, and it WORKS. Extremely well, I might add. (It's what I am using right now under FreeBSD with Linux compatibility turned on.) Now she's happy as can be... And I know for a FACT that I will not buy a computer with Windows XP. And I am pretty disappointed with Netscape once again (not so much for the crash, but very much so because of the clutter), as I have been for several years. (Yes, I will continue trying it from time to time, because somewhere deep inside, I believe that it will BECOME a very good, reliable web browser. I just wish it'd become as SMALL as Opera (3 megs or so) and as fast. Netscape is very, very slow.)

    I hope if any Netscape developers are reading this, that they'll take this as constructive criticism rather than as flamebait. Oh yeah. And YES, I know the Gecko engine is found in Galeon and several other browsers.

APL is a write-only language. I can write programs in APL, but I can't read any of them. -- Roy Keir

Working...