Address book developments

[Mike Conley]

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-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

[Ludovic Hirlimann]

On 2/11/13 12:41 AM, Mike Conley wrote:
>
> 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?

Go for it Mike. As we need to time to iron out things to get things at a
high quality level. !!!


Ludo

[acel...@atlas.sk]

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" <mco...@mozilla.com>
> Komu: <tb-pl...@mozilla.org>
> Dátum: 11.02.2013 00:41
> Predmet: Address book developments

[Mark Banner]

On 11/02/2013 10:19, acel...@atlas.sk wrote:
> 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?

Things like nsISupportsArray removals, should go on regardless - because
of the m-c dependency. For example, we don't yet know when m-c will be
ready to fully remove nsISupportsArray, but given the current focus, I
think we can bet on it happening as soon as the person working on it can
get reviews and everything landed.

Other changes, should probably be a balance of time versus improvement,
although from the way I read Mike's email, Ensemble won't be in 24 there
will just be some improvements to make it work with 24 - so there will
be at least one more release with all these improvements in.

Mark.

[acel...@atlas.sk]

________________________________________________
> Od: "Mark Banner" <mba...@mozilla.com>
> Komu: "tb-pl...@mozilla.org" <tb-pl...@mozilla.org>
> Dátum: 13.02.2013 11:45
> Predmet: Re: Address book developments

>
>On 11/02/2013 10:19, acel...@atlas.sk wrote:
>> 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?
>Things like nsISupportsArray removals, should go on regardless - because
>of the m-c dependency. For example, we don't yet know when m-c will be
>ready to fully remove nsISupportsArray, but given the current focus, I
>think we can bet on it happening as soon as the person working on it can
>get reviews and everything landed.

I couldn't find any focus on nsISupportsArray removal from m-c.
Where is the bug with patches you talk about? I couldn't find anything relevant from the meta bug 792209.

[Mark Banner]

On Wed Feb 13 11:24:22 2013, acel...@atlas.sk wrote:
> ________________________________________________
>> Od: "Mark Banner" <mba...@mozilla.com>
>> Komu: "tb-pl...@mozilla.org" <tb-pl...@mozilla.org>
>> Dátum: 13.02.2013 11:45
>> Predmet: Re: Address book developments
>>
>> On 11/02/2013 10:19, acel...@atlas.sk wrote:
>>> 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?
>> Things like nsISupportsArray removals, should go on regardless - because
>> of the m-c dependency. For example, we don't yet know when m-c will be
>> ready to fully remove nsISupportsArray, but given the current focus, I
>> think we can bet on it happening as soon as the person working on it can
>> get reviews and everything landed.
>
> I couldn't find any focus on nsISupportsArray removal from m-c.
> Where is the bug with patches you talk about? I couldn't find anything relevant from the meta bug 792209.

That would probably be the right bug, but it could be the folks working
on it haven't found/started using it yet... but the fact that the
nsITreeView bug is being worked on and there's been a bunch of other
bugs that have been closed by the same person within the last couple of
months
(https://bugzilla.mozilla.org/buglist.cgi?list_id=5674670;short_desc=nsISupportsArray;resolution=FIXED;chfieldto=Now;chfield=resolution;query_format=advanced;chfieldfrom=-2m;short_desc_type=allwordssubstr),
indicates to me that someone is working on it ;-)

Mark

[acel...@atlas.sk]

______________________________________________________________
> Od: "Mark Banner" <mba...@mozilla.com>
> Komu: <acel...@atlas.sk>
> Dátum: 13.02.2013 12:34

> Predmet: Re: Address book developments

>>> Things like nsISupportsArray removals, should go on regardless - because
>>> of the m-c dependency. For example, we don't yet know when m-c will be
>>> ready to fully remove nsISupportsArray, but given the current focus, I
>>> think we can bet on it happening as soon as the person working on it can
>>> get reviews and everything landed.
>>
>> I couldn't find any focus on nsISupportsArray removal from m-c.
>> Where is the bug with patches you talk about? I couldn't find anything relevant from the meta bug 792209.
>
>That would probably be the right bug, but it could be the folks working
>on it haven't found/started using it yet... but the fact that the
>nsITreeView bug is being worked on and there's been a bunch of other
>bugs that have been closed by the same person within the last couple of
>months
>(https://bugzilla.mozilla.org/buglist.cgi?list_id=5674670;short_desc=nsISupportsArray;resolution=FIXED;chfieldto=Now;chfield=resolution;query_format=advanced;chfieldfrom=-2m;short_desc_type=allwordssubstr),
>indicates to me that someone is working on it ;-)
>
>Mark

Yeah, I was only counting the linked OPEN bugs :) That they do not cover the remaining usages in m-c. Yes, he is creating and linking new bugs as he progresses. I do the same for c-c I just link them to our c-c meta bug.