Thunderbird/Protovis

This page is about tracking the decisions & discussions needed before we land Protovis in tree.

• determine who "maintains" protovis in the tree. (That means: be aware of important changes in protovis, be willing to help upstream issues, and bridge between the two projects). --> asuth first, then davida?
• determine what version to use --> latest stable 2.x version by the time RC1 is built?
• Sort out licensing issues.
  • See the license policy
  • This includes emailing the license team (step 6) to get their ok. [email sent; approval obtained]
  • Do we need to get about:license updated? [gerv says: yes]
• decide where to land the file. Currently in mail/base/content/protovis-2.x.js
  • (Standard8) I expect this would have to go in other-licenses/ - it would be best to keep it separate anyway so we don't cloud tri-license and non tri-license code. See "Third Party Code" here.
  • (DavidA) Actually, for BSD code, Gerv says we don't have to do that -- it's recommended that it be in its own directory, but it doesn't have to be in the other-licenses ghetto.
• understand the protovis security profile
  • background: protovis is a visualization library which creates svg or canvas nodes. It's all javascript.
  • protovis is loaded in html chrome by thunderbird core features.
  • Note: protovis is intended for "content", but is used in chrome. Does that matter?
    • does protovis have any implicit dependencies on content-space features (eg cross-domain restrictions)?
  • possible TODOs:
    • figure out if there are any obvious security concerns (use of eval() on input vars)
    • talk to someone in security about it, get their 2c.
      • are there likely to be unintended consequences of using protovis with
        • XUL
        • XBL
        • XPConnect and the various wrapper objects
    • talk to the authors of protovis, see what they have to say about security implications.
• understand the upgrade/maintenance policies around protovis
  • how long do they expect version 2 to be maintained?
  • we will decide when new versions are released whether to include them in trunk, and whether to include them in branch, based on the specific changes in each release.
• do the protovis authors have concerns about protovis inclusion in tb3?
• decide what the level of support for protovis is from Mozilla's POV. Draft:

Protovis is included in Thunderbird for two reasons -- one, because it makes it possible for us to deliver specific features, and two, because we feel it can be useful to add-on authors. Mozilla are not the primary authors of Protovis, however, and we will endeavor not to fork the version of Protovis in Thunderbird if at all possible -- instead, we will work to fix the library up-stream, and when it updates (with fixes from us or from others), then we'll consider updating it in later releases of Thunderbird (whether minor or major version upgrades). If you encounter problems with Protovis in your add-on development, we encourage you to engage with its community at <url>.