Followup to bug 241197 -- or -- feedback from an extension developer
sid1337 at gmail.com
Thu Mar 18 20:55:53 UTC 2010
On 18-03-2010 03:12, Jonathan Protzenko wrote:
> There also seems to be some overlap between what is being rewritten
> and what is legacy code. That's normal but it can get confusing
> sometimes. For instance, there exist both GetMsgFolderFromUri and
> MailUtils.getFolderForURI. But, look, there's this wonderful
> nsIFolderLookupService :: getFolderById !  Wait, there's an
> interface but no implementation ? Oh sure, that's bug 441437... the
> implementation was there before but was backed out. An "official
> reference" would be helpful there.
That change is my fault -- IIRC I introduced MailUtils.getFolderForURI
as part of a large patch, and I didn't want to complicate the patch
further by renaming GetMsgFolderFromUri to MailUtils.getFolderForURI
everywhere. So I made GetMsgFolderFromUri a wrapper around
MailUtils.getFolderForURI, as you can see at
and slapped a @deprecated on it.
You're right in that I should have filed a followup bug to remove
GetMsgFolderFromUri entirely. Care to do it?
> The ideal solution would be to have some .jsm that offers helpers for
> the most common actions. I've been doing this more or less for my
> extensions, but I think there should be some "official" way of doing
> this. If this is too hard to maintain, I think updating the
> Thunderbird how-to list on MDC would be a nice alternative. I plan to
> do some of it myself, but I'm no Thunderbird developer and I might not
> always write the best solution.
That's sort of what MailUtils
was intended to be -- and it is deliberately a module so that all sorts
of code -- chrome, component and module -- could use it, but I do
realize that it lacks a number of helpers that would be useful. (As far
as I know, we've added functions to it mostly as we've needed them
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning