Full Article Attached Mozilla Looking to Forge Alliances with GNOME and Other Open Source Projects to Combat Longhorn

Tuesday April 6th, 2004

jgraham writes: "Brendan Eich has written an interesting post to the netscape.public.mozilla.seamonkey newsgroup outlining some of the plans being made to ensure that Mozilla technology remains useful and relevant in the future. Brendan sees Mozilla developing into an open cross-platform alternative to forthcoming Microsoft technologies such as XAML and is looking to collaborate with other open-source projects to make this happen." The GNOME project is mentioned explicitly. Brendan's message is part of a longer thread about the goals of

#32 Re: The XUL Naming Debate Is Over

by Asacarny

Wednesday April 7th, 2004 10:43 AM

You are replying to this message

<i>Well, XUL/XUI/XAML/UML/WML/etc. it's all the same. Whatever acronym you pick someone will always complain.</i> Actually, XUIL isn't taken. Search google for it. Fewer than 400 mentions on the whole web. I don't think you'd get any complaints. But that's not your agenda, is it?

It even sounds cool. Zoyle. Unfortunately, "XUIL" is not going to match a google search for "XUL".

<i>Well, isn't it ironic that a dozen project leads take part in the XUL Grand Coding Challenge 2004 but Mozilla is missing?</i> Being that there are so many great applications already written in XUL, I think that Mozilla's absence says less about Mozilla and more about the XUL Grand Coding Challenge. But you know that. You create these "important" "XUL" "events" so that you can become a host for some "revolution". Because what we really need is a coding challenge, right?

<i>You seem to be new to the XUL discussion.</i> Only if the XUL discussion means replying to you. Re: XUL standards, you're right that Hixie wasn't working on submitting XUL. I misread his blog. But you make a major error when you talk about a lack of cross-browser support for XUL. We can already see that coming along. KDE has created a framework for transforming XUL code into native widgets, with javascript already working and CSS coming.

Consider that even if the standard is controlled by Mozilla, its reference implementation operates under the tri-license, which allows easy code reuse. Anyone who seeks to reimplement XUL, whether the spec is controlled by Mozilla or not, can easily look at the source code. That makes Mozilla's position with respect to XUL different from, say, Netscape or Microsoft with respect to HTML. The extensions Netscape and Microsoft made to HTML had to be reverse-engineered: open spec, closed implementation. Any extension Mozilla makes to XUL will be completely transparent, with the source code at any reimplementor's fingertips.

As for XForms, I didn't know much about the issue, so I fired up Bugxula. (A useful app written in XUL. Joy!) Don't listen to Gerald, just check bug 97806. It reveals that Mozilla developers are wary of the XForms spec (just because it's W3C doesn't make it good, just because it's a standard doesn't mean it must be supported), but would be very much willing to consider including XForms support if someone steps up to develop it. They make no promises, but for the moment would at least support XForms as an extension.

You would have a real gripe about XForms support if Mozilla had actually rejected some hard code. Why don't you implement it for Mozilla, and then see what happens?