2005Offsite/StandardizingXul

< 2005Offsite
Revision as of 11:44, 6 December 2005 by Nitot (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

< back to offsite schedule

An open brainstorming session on why XUL could/should be made interoperable and/or standardized.

Topics for discussion

Here are a few questions we may use to fuel the discussion (feel free to add some more):

Next-generation Web apps

Ajax' success is demonstrating the need for new-generation apps, but XUL is much more powerful (structured/accessible/semantically-rich) than AJAX. Do we want to innovate in this space?

Competition

Macromedia, with Flash, has already amazing market dominance

  • With Microsoft XAML around the corner, with Macromedia FLEX gaining speed, how are we going to respond?

General questions

  • What do we want to achieve with XUL?
  • Do we want XUL to be the next big thing?
  • Do we want to lock-in our customers or play nice?


[Udell on XAML and FLEX ] sums it up quite nicely:

> We had a great thing going for about 10 years: the universal HTML/JavaScript client. And while it's still a great thing, there are good reasons to advance the state of the art. But can we please, please not lose the standardization that's served us so well?


I (Tristan) would love to discuss the opportunity to standardize XUL and make it interoperable. There are two good reasons for this to be considered:

  • With XAML around the corner, with Microsoft having a huge leverage with their developer community and set of tools (and marketing dollars), being open-source and an open-format is our way to make sure that our innovations are going to make a dent in the market;
   * We probably do not want the web to balkanize the Web with XUL / XAML / FLEX just like it used to be in Browser War I with (D)HTML.