Calendar:Lightning:Integration Issues - Revision history

Sburke: Mork -> Mork

2006-01-21T03:59:54Z

Mork -> Mork

← Older revision		Revision as of 03:59, 21 January 2006
Line 14:		Line 14:
	** Can't participate in server/folder model without security-risky, leak-prone, JS-incompatible RDF work.		** 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.		** Also need to implement large and baroque nsIMsgIncomingServer and nsIMsgFolder interfaces.
	** MsgDbHeader stuff looks very ~~mork~~-centered, hard to use with other stores.		** 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.		* 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.

Shaver at 15:43, 6 April 2005

2005-04-06T15:43:53Z

← Older revision		Revision as of 15:43, 6 April 2005
Line 34:		Line 34:
	* 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.		* 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.

	* ~~DOMi and~~ Venkman ~~don~~'t work well with Thunderbird -- DOMi ~~was dropped in Tbird 0.8 for DL-size reasons~~, ~~and people said it was~~ available ~~as an extension, but I can only find an old one from Chris Neale that I have to hack install~~.~~rdf for~~.		* 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.		* Overlaying new columns into tree widgets is hard. And by hard, I mean impossible.

ChrisHofmann at 21:52, 1 April 2005

2005-04-01T21:52:42Z

@@ Line 1: / Line 1: @@
 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.
 --[[User:Shaver|Shaver]] 10:51, 30 Mar 2005 (PST)
 * Little-to-no error reporting for overlay errors.
@@ Line 14: / Line 35: @@
 * DOMi and Venkman don't work well with Thunderbird -- DOMi was dropped in Tbird 0.8 for DL-size reasons, and people said it was available as an extension, but I can only find an old one from Chris Neale that I have to hack install.rdf for.
 * 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.

Shaver at 19:25, 30 March 2005

2005-03-30T19:25:49Z

← Older revision		Revision as of 19:25, 30 March 2005
Line 11:		Line 11:
	* 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.		* 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, let alone where JS components change, etc.		* 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.

	* DOMi and Venkman don't work well with Thunderbird -- DOMi was dropped in Tbird 0.8 for DL-size reasons, and people said it was available as an extension, but I can only find an old one from Chris Neale that I have to hack install.rdf for.		* DOMi and Venkman don't work well with Thunderbird -- DOMi was dropped in Tbird 0.8 for DL-size reasons, and people said it was available as an extension, but I can only find an old one from Chris Neale that I have to hack install.rdf for.
Line 19:		Line 19:
	** Also need to implement large and baroque nsIMsgIncomingServer and nsIMsgFolder interfaces.		** Also need to implement large and baroque nsIMsgIncomingServer and nsIMsgFolder interfaces.
	** MsgDbHeader stuff looks very mork-centered, hard to use with other stores.		** 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.

	* Overlaying new columns into tree widgets is hard.		* Overlaying new columns into tree widgets is hard. And by hard, I mean 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.		* 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.
Line 35:		Line 36:
	* xpcshell doesn't work well with components installed in firefox/tbird profiles, which makes reproducing and testing bugs/fixes much harder.		* xpcshell doesn't work well with components installed in firefox/tbird profiles, which makes reproducing and testing bugs/fixes much harder.

	* 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.		* 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.)

Shaver at 19:19, 30 March 2005

2005-03-30T19:19:42Z

← Older revision		Revision as of 19:19, 30 March 2005
Line 9:		Line 9:
	** No useful error reported at _any_ point.		** No useful error reported at _any_ point.
	* Some, but insufficient, for chrome.manifest/chromereg.		* Some, but insufficient, for chrome.manifest/chromereg.
	* Also, extension manager ~~stuff~~. (Some of that is because the RDF datasource stuff sucks, and doesn't report errors back up the chain.)		* 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, let alone where JS components change, etc.		* Reload-to-test cycle painful -- can't even use "reload chrome" extension in tbird for those cases, let alone where JS components change, etc.

Shaver at 19:07, 30 March 2005

2005-03-30T19:07:48Z

← Older revision		Revision as of 19:07, 30 March 2005
Line 34:		Line 34:

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

			* 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.

Shaver at 18:51, 30 March 2005

2005-03-30T18:51:38Z

← Older revision		Revision as of 18:51, 30 March 2005
Line 1:		Line 1:
	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.		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.
			--[[User:Shaver\|Shaver]] 10:51, 30 Mar 2005 (PST)

	* Little-to-no error reporting for overlay errors.		* Little-to-no error reporting for overlay errors.

Shaver at 18:48, 30 March 2005

2005-03-30T18:48:53Z

← Older revision		Revision as of 18:48, 30 March 2005
Line 31:		Line 31:

	* 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?		* 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.

Shaver at 18:44, 30 March 2005

2005-03-30T18:44:48Z

New page

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.

* 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 stuff. (Some of that is because the RDF datasource stuff sucks, and doesn't report errors back up the chain.)

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

* DOMi and Venkman don't work well with Thunderbird -- DOMi was dropped in Tbird 0.8 for DL-size reasons, and people said it was available as an extension, but I can only find an old one from Chris Neale that I have to hack install.rdf for.

* 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.

* Overlaying new columns into tree widgets is hard.

* 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.

* 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!

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

* 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?