Calendar:Lightning:Integration Issues

This is a very rough doc; I use it to keep track of problems we need to address for Lightning and likely for other extension authors as well. I need to find/file bugs on these to track and suggest improvements in. --Shaver 10:51, 30 Mar 2005 (PST)

Thunderbird Related Issues and Implementation Ideas

• Would be nice to be able to use IMAP as a calendar store, and maybe for centralized prefs, etc., but driving the IMAP protocol code from non-mailnews apps looks to be Very Hard. (Just analyzing the IMAP protocol code is Very Hard, in fact, due to the multi-variable state machines.)

• Can't search addressbook
  • Have to retrieve all cards and enumerate (!)
• hard to plug in new addressbook implementations (more RDF stuff, painful interfaces)
  • The GroupDAV guy is suffering under this, proposing new ifaces, stuck between a rock and a hard place!

• Need to participate in the folder/server/msgdbheader model to get into the Tbird search model.
  • Can't participate in server/folder model without security-risky, leak-prone, JS-incompatible RDF work.
  • Also need to implement large and baroque nsIMsgIncomingServer and nsIMsgFolder interfaces.
  • MsgDbHeader stuff looks very Mork-centered, hard to use with other stores.
• Similarly with the threading model; having calendar events threaded into email discussions resulting from the invitations (quite common, I find) looks to be largely impossible.

• Everyone seems to have to write their own "is a message selected?" sorts of command handlers, since we don't have any good ones to reuse.

• Thunderbird skin/chrome build system very confusing, with classic and qute and mailnews and mail. Some docs or fixes there would be greatly helpful.

General Platform Development Issues

• Little-to-no error reporting for overlay errors.
  • Put an incorrect URL in your chrome.manifest
  • Causes an empty buffer to be sent to expat
  • Which is an XML error, causing the XUL content sink to generate <parsererror> _and_ blow away the context stack.
  • You get an assertion from the context stack destruction, and future overlay processing is broken.
  • No useful error reported at _any_ point.
• Some, but insufficient, for chrome.manifest/chromereg.
• Also, extension manager error reporting is sorely lacking. Some of that is because the RDF datasource stuff sucks, and doesn't report errors back up the chain. F.e. update.rdf served as wrong (but RDF-legal: application/rdf+xml) MIME type.

• Reload-to-test cycle painful -- can't even use "reload chrome" extension in tbird for those cases (it doesn't work), let alone where JS components change, etc.

• Venkman doesn't work well with Thunderbird. (DOMi now works on the trunk, though there's still nothing available for the 1.0.x line.)

• Overlaying new columns into tree widgets is hard. And by hard, I mean impossible.

• Venkman doesn't help at all for debugging with JS component issues for which we have well-isolated (xpcshell) test cases; have to choose between running easily in xpcshell and having venkman available (by loading it into tbird or such). Maybe xulrunner can help here?

• xpcshell doesn't work well with components installed in firefox/tbird profiles, which makes reproducing and testing bugs/fixes much harder.