RoboGeek

RoboGeek's (David Herron) Weblog: co-developer of Robot and several other things related to Java testing.

All | Corporate Blogging | ecological computing | General | Java | Podcast

« Can Sun and Microsof... | Main | Why Bush must lose,... »
20040804 Wednesday August 04, 2004

More on Mozilla messiness

On this page http://www.mozilla.org/xpfe/ we have an overview of XPToolkit, or the "Cross Platform Toolkit" which is the module that allows Mozilla applications to be cross-platform.

Notice towards the bottom a link for the clipboard service. The clipboard is the facility through which drag and drop and other style of datatransfer between applications occurs. The link refers to this page:

http://www.mozilla.org/xpfe/xptoolkit/clipboard.html

Towards the end of that page there is an example of using the clipboard. As a code sample it is pretty nice, simple, easy to understand, and I value having it there. However ...

Let's back up a little and talk about the Mozilla architecture a bit. The design is to have a pile of loosely coupled components or modules. The name is "XPCOM" or cross-platform common-object-module. Any service you use in Mozilla, you first must get an XPCOM style handle onto the service. The XPCOM layering allows XPCOM modules to be used from "any" programming language (for which XPCOM bindings have been created). The list includes javascript, C++, python, Java, perl, etc (the usual suspects).

From Javascript the idiom is:

   var xyz = Components.classes[class-id].getService();
   xyz = xyz.QueryInterface(Components.interfaces.nsIXyz);

The "class-id" is a string with a form like: "@mozilla.org/network/server-socket;1". The "nsIxyz" identifier refers to the interface description (by convention) stored somewhere as a file named nsIxyz.idl. This is nice and loosely structured allowing a great deal of flexibility in bringing pieces and parts together to make an application.

HOWEVER ... If you look at the example you see:

var clipboard = Components.classes["component://netscape/widget/clipboard"].getService();
...
var trans = Components.classes["component://netscape/widget/transferable"].createInstance();
...

When I copied that code into my application it failed. Why? Because it didn't recognize the class-id string. Why? Well, probably the documentation is out of date. Why? HeckifIknow, I sure don't know why the mozilla.org team is presenting bad or wrong documentation as the way to do things.

Here's the problem -- it's not at all obvious what the class-id string for a given IDL interface is. The class-id string is not given in the IDL file, but is stored elsewhere. Where? I haven't been able to determine a search pattern which will always result in finding the class-id string. Sometimes it is located in a ".h" (header) file related to the class, but not always.

In the case of the clipboard and transferable objects they ended up located here:

http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/nsClipboard.js

http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/nsTransferable.js

It was nice to be able to find this - however, these class-id strings are such a crucial part of writing code for Mozilla that it's absolutely outrageous that it is so difficult to find them.

(2004-08-04 10:41:39.0) Permalink Comments [2]

Comments:

I assume you have checked out http://xulplanet.com/references/xpcomref/frozen.html ? Browse the interface and there you have class ids, no?

Posted by Martin Enlund on August 04, 2004 at 02:59 PM PDT #

Announcement about a Speakers Panel on Current Web Browsers

As we continue to see rich-GUI Web software slide into proprietary formats, and the pressure on Microsoft to play nicely from legal battles ease, the time is right to address the future of the Web.� I would like to invite you to come to a speaker panel at <a href="http://west.cmu.edu/" target="_blank">Carnegie-Mellon University's West Coast Campus, at Moffett Field (45 minutes south of San Francisco), entitled, "Back to Proprietary Client-Server, or Web Renaissance?", on November 10th, 2004, at 6:30pm.�

Every single person I know who has spent one year or more of full-time work doing intensive JavaScript/DOM by the w3c standards (including myself) feels that Mozilla, and especially Safari, are blights and should be released as "experimental" browsers until their bugs are fixed. I'm looking for more panelists who can speak to this "controversial" issue. Please contact me at cbalz at andrew.cmu.edu if you have suggestions for panelists. So far, I have some very good speakers signed up for the panel.

Details:

In this panel, I would like to have the panelists speak to the following questions:</div>
  • What role did open standards (specifically, HTTP and HTML) play in the initial adoption (from 1994 onward) of the Web and its development into a giant new business market and more?
  • How did these open standards come to take hold?� What were the major obstacles?� Was the driving force to adoption a mix of technological evangelism and market forces?�
  • Compare and contrast HTML�to�DHTML (Dynamic HTML) with the JavaScript binding.
  • Give your perspective on client-side Web software development, and its importance today on the Web.�
    • What is the importance of Dynamic HTML and the binding to JavaScript on the Web today?
    • Do you view the application of OO techniques to JavaScript, particularly simulation of Java-like class-based inheritance in JavaScript, as helpful in deploying Web software?
  • Is JavaScript a more realistic choice on the Web than Java for the client-side of consumer Web applications, due to JavaScript's current near-ubiquity, lack of need for installation, fast start-up time, and security (especially, it's lack of a file API)?
  • Give your view of the pros and cons of server-centric Web development (i.e., JSP, ASP) as opposed to a Web based on the distributed application or client-server concept.�
    • What are the pros and cons to the consumer Web user, who needs high usability, interactivity,�and speed, on dial-up and on high-speed?
    • What are the pros and cons to the server center, from the perspectives of IT (i.e., scalability), engineering, and security?
  • Why is it that the "other" Web browsers -- the non-Microsoft Web browsers -- do not support the W3C standards correctly enough to support building "next generation" Web applications based on public Web standards?
  • What is the impact of this situation, as we see rich-GUI Web applications migrate to proprietary formats such as Flash and IE-specific?
    • What are the security implications of a Web highly fragmented among Flash browsers, Microsoft Longhorn Client browsers, Web-standard browsers, and Internet Explorer-specific Web sites?�
      • Would this amount to an unmanageable blizzard of security patches for consumers?
  • What can be done to improve the support of Web browsers for rich-GUI Web applications built solely on W3C standards?�
    • Would an industry consortium be an appropriate vehicle for this task?
    • Can the market alone, in its current state, take care of this situation?
    • Is technological evangelism needed?
  • Imagining a supportive climate for distributed Web applications built on Web standards, what market spaces would this create?
    • What would be the role of current vendors of traditional Web application frameworks, such as BEA, IBM, and Sun/Netscape?

Posted by Christopher M. Balz on September 29, 2004 at 04:51 PM PDT #

Post a Comment:

Comments are closed for this entry.