Re: Address book developments

acelists at atlas.sk acelists at atlas.sk
Mon Feb 11 10:19:54 UTC 2013


Hi.

I have these proposals:
1) can you use help from some module owners to hook up the new addressbook? If yes, you could make some page/list of bugs and assign some work to them. So that you can focus on the addressbook core. Of course I don't know it they will cooperate, but you can try it :) I think rkent feels the lack of vision in TB (future planing) and this could be a good chance to try out some leadership and organization of work.
2) on that page, can you provide some hints to other developers on the state of the /mail*/*/addressbook/* files? Will all those files go away and we should no longer put any effort into updating them (e.g. nsISupportsArray removal, JS updates (for..of, string manipulations)). Or will they just get slightly modified when the new AB lands?

Or is it too early for these?

aceman

______________________________________________________________
> Od: "Mike Conley" <mconley at mozilla.com>
> Komu: <tb-planning at mozilla.org>
> Dátum: 11.02.2013 00:41
> Predmet: Address book developments
>
>Hello everybody,
>
>So I've been actively working on Ensemble (my code-name for the address 
>book rebuild), and I've decided to set a goal for Thunderbird 24, and I 
>wanted some feedback.
>
>The initial roadmap I had set for Ensemble puts Thunderbird integration 
>far towards the end. I think I'd like to alter that roadmap, and start 
>making some changes in mailnews / mail to allow for Thunderbird to 
>access Ensemble's contact store, and to use it for populating 
>autocomplete inputs, as well as the "From" field in the thread pane. I 
>might put message filter support in that list as well.
>
>This is my general thinking:
>
>1) Start by moving the "allow remote content" whitelist out of the 
>address book, and into something else. This is bug #457296, and Mark / 
>Irving have made some good inroads here. Mark has a WIP patch that gives 
>us a new, separate whitelist component. Irving has an alternative patch 
>that would allow us to use nsPermissionManager with the mailto: scheme 
>as our whitelist.
>
>Irving's patch is currently stuck in review-hell (it looks like nobody 
>really wants to pony up the time to weigh in on nsPermissionManager 
>patches).
>
>I'd like to lean on this bug a bit, and see if I can get a firm answer 
>on how to move forward. Once we have a direction, we make the necessary 
>alterations, and write some migration script to move the data from the 
>current address book to the new mechanism.
>
>2) Create a new, more general interface for Thunderbird to query the 
>address book about things. nsIAbManager currently exposes too much 
>information to the caller, and Ensemble will certainly not be 
>implementing this interface.
>
> From what I can tell, this interface, very generally, needs to do the 
>following:
>
>* Provide a list of the "sub-lists" of contacts
>* Be usable by nsMsgDBView to populate the Author / Recipient cells in 
>the thread-pane.
>* Increment a notion of popularity for a particular email address 
>(although, arguably, Ensemble could listen for send events and handle 
>this internally)
>* Allow Thunderbird to query for whether or not an address belongs to a 
>particular sub-list (for spam whitelisting, for example)
>* Allow Thunderbird to query for whether or not an address exists within 
>the entire contact store
>
>I don't think nsIAbCard is the best way to represent contacts through 
>this new interface. Instead, I suggest that contacts be represented 
>using the Contacts API nsIDOMContact interface. This is a modern 
>interface that is likely to be maintained and extended as contact 
>management evolves.
>
>I also find it likely that if Firefox ever starts managing contacts 
>(which it might - SocialAPI and WebRTC seem to hint at it), my best 
>guess is that it will use this interface for Firefox OS interoperability.
>
>So it might be in our best interests to adopt this interface for 
>querying for contacts within Thunderbird.
>
>Anyhow, this is getting really long.
>
>TL;DR: I want to move the "allow remote content" out to 
>nsPermissionManager (bug 457296), and I'm going to lean on that. I'm 
>going to design and write a more general contact querying interface for 
>Thunderbird's internals, and use nsIDOMContact as the contact 
>representation interface.
>
>Thoughts? Concerns? Am I walking into a minefield?
>
>-Mike
>_______________________________________________
>tb-planning mailing list
>tb-planning at mozilla.org
>https://mail.mozilla.org/listinfo/tb-planning
>



More information about the tb-planning mailing list