tomorrow's 12:30 PDT meeting

Mike Shaver shaver at
Thu, 12 Aug 2004 16:28:45 -0400

This is a multi-part message in MIME format.
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Brendan Eich wrote:
> Agenda, semi-ordered:
> - Canvas news

- Vlad and Stuart in conversation with Apple rep about API changes, 

> - Cairo status

- License discussions continue, some progress being made.
- Discussion of forking last X11-based Cairo with Mozilla

> - XULRunner progress (see -- 
> but I object that XUL is not a word! ;-)

- Ran (trivially-modified) chatzilla as a XULRunner app!
- Working on win32 icon stuff
- May need help with OS X equivalent
- Can be landed in 1.8a4.

> - SVG status and turn-on criteria

- Criteria sent to drivers: (attached)
  * font-size in
  * switch still under review
  * gradients not in yet, patch needs updating
  * <use> not in yet
- Do we need a security audit to go with upcoming SR?
- Might make end of 1.8a4?

> - XTF integration patch status, landing plan

- Waiting on jst for review and polishing (Tuesday)
- 1.8a4 likely
- Seems to be in good shape

> - XForms news

- Announcement out; not clear enough that it's an extension
- IBM working on XPath improvements as part of it, hiring Sicking!
- Integrating Novell dep-graph code
- Once XTF lands on the trunk, would maybe be able to work off trunk,
   branching during "quiet periods"

> - A generic one-click download-and-install managed extension model for 
> SVG, XForms, and other such Gecko extensions

- plugin-manager : mime-type :: dropin-content-hoohah-manager : namespace
- may require vendor/packaging support for update as well

> - RDF story next steps

- BRQL is "SQL for RDF data stores"
  = hard for dynamic update of data representation?
  = leverages SQL syntax heavily
- How do we wrap it up in XML?
- How complex/rich do we want our query language to be?
- How does the query language affect API size, performance?
- Is the query language too tied to RDF?

> - XUL2 prioritization of Neil's list, other actions

Homework: read and comment in

- shaver to schedule RDF call for more detailed discussion

MonoConnect progress:
  - can invoke XPCOM methods from C#, IronPython.
  - need component loader, better native->CLR calling


Content-Type: message/rfc822;
 name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Attached Message"

Return-Path: <>
Received: from ( [])
	by (Postfix) with ESMTP id 168E8770008
	for <>; Mon, 26 Jul 2004 21:04:42 -0400 (EDT)
Received: from (localhost.localdomain [])
        by  with ESMTP id i6R144Ga022038;
	Mon, 26 Jul 2004 18:04:04 -0700
Received: from ( [])
        by  with ESMTP id i6R13IGa021714
	for <>; Mon, 26 Jul 2004 18:03:18 -0700
Received: from localhost (localhost [])
	by (Postfix) with ESMTP id 318CBBBE37
	for <>; Mon, 26 Jul 2004 18:03:33 -0700 (PDT)
Received: from ([])
	by localhost ( []) (amavisd-new, port 10024)
	with ESMTP id 30233-87 for <>;
	Mon, 26 Jul 2004 18:03:33 -0700 (PDT)
Received: from ( [])
	by (Postfix) with ESMTP id 66E5A336BCD
	for <>; Mon, 26 Jul 2004 13:05:51 -0700 (PDT)
Received: from localhost (localhost [])
	by (Postfix) with ESMTP
	id CBF1FD877F; Mon, 26 Jul 2004 16:05:47 -0400 (EDT)
Received: from ([])
	by localhost (salt []) (amavisd-new, port 10024) with ESMTP
	id 14795-01; Mon, 26 Jul 2004 16:05:47 -0400 (EDT)
Received: from ( [])
	by (Postfix) with ESMTP
	id E0302D8859; Mon, 26 Jul 2004 16:05:46 -0400 (EDT)
Received: from (fred [])
	by (Postfix) with ESMTP
	id 87C8C3CD1; Mon, 26 Jul 2004 16:05:46 -0400 (EDT)
Received: (from tor@localhost)
	by (8.9.0/8.9.0) id QAA06086;
	Mon, 26 Jul 2004 16:05:46 -0400 (EDT)
From: Tim Rowley <>
Subject: SVG switch-on requirements
Message-ID: <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at
X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=5.0 tests=
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: <>
List-Post: <>
List-Subscribe: <>,
List-Id: <>
List-Unsubscribe: <>,
List-Archive: <>
Date: Mon, 26 Jul 2004 16:05:46 -0400

The mozilla SVG contributors (afri, scooter, jwatt, tor) recently
discussed turn-on criteria for SVG.  The issues we felt needed to
be addressed before this could happen were the following:

  * stability - it's thought that many of the problems here are
    caused by libart.

  * tri-license friendly distributions for all tier-1 platforms

      * win32 - GDI+ is redistributable, so I think we could
        include it in the package.

      * linux - libart is LGPL, so isn't acceptable.  cairo has a
        MIT/BSD style license, so we could statically link this
        (needed because the API is still shifting).

      * macos - outside possibility of using cairo.  A quartz
        backend is currently stalled.

  * finishing off features currently in code review - gradients,
    switch, font-size

  * <use> is an outstanding missing feature

  * super-review of all svg code

Note that this will still bring us up well short of SVG Tiny,
much to the annoyance of the W3C.

What sort of timeframe would be you be interested in having SVG
for?  I believe brendan floated the idea of 1.8.  If we had a
commitment for that and could arrange the svg module
super-review, we could probably get the entire list except for

Footprint for this feature on linux would be about 300K plus 170K
for cairo.

We would be interested in any comments you might have on this