Not too long ago, a discussion started in this newsgroup about what
providers should ship with Sunbird and Lightning.  The provider that
provoked this discussion was WCAP, and it became apparent that in order
to get to the point of figuring out exactly what is and isn't reasonable
to include in the default builds, we're going to probably end up
formulating some sort of policy, as is the Mozilla way.  For those not
familiar with it, WCAP is the protocol implemented by the Sun Java
System Calendar Server and documented at
<http://docs.sun.com/app/docs/doc/819-2434/6n4nme465?a=view>.

In the interest of getting 0.3 out the door without having to have a
long involved discussion first, we (the Calendar owners) met with the
WCAP contributors and came up with an alternate plan for 0.3.

The idea is to ship a "Lightning" XPI and a "Lightning+WCAP" XPI (the
latter of which will be a multi-package XPI that contains two separate
extensions: "Lightning" and "WCAP").  The WCAP extension is currently
planned to enable both the WCAP provider and a prototype event dialog
developed specifically for use with that provider.

Given that this solution for provider distribution doesn't really scale,
it's pretty much guaranteed that it's not going to be our real solution
for 1.0. So the plan is to explicitly say so on the download page and
release notes.

Is this a great solution?  Not even close.  However, it has the key
advantage that we get to ship something to multiple constituencies
without having to have a ton of policy discussion and delaying 0.3 even
further.  We also get feedback from different groups of users, and
information about WCAP demand.

The upshot of this is that soon, there will be multiple Lightning XPIs
generated by the Tinderboxen.  The WCAP contributors will be handling
the QA for the "Lightning+WCAP" packages, though I suspect that if folks
from the community are interested in chipping in, they'll be more than
welcome.

Dan