The verbs above suggest "how" the contact was acquired. I wonder
whether a bit more information is required to get to "where" the contact
came from. For example:
> - Collected
I think it'd be nice for Thunderbird to remember which email drove the
auto-collection. Or at least some attributes of it, like From/To.
I use multiple email identities and I'd like to separate out the
addresses collected under each identity. Ideally at collection time (a
filter rule?) but if it can be done after collection that'd be a good
> - Sync
The sync endpoint that generated the contact might make a useful
attribute. For example, "created by Sync with mobile phone" or "created
by sync with server blah". If Thunderbird is to play a role as a Sync
Hub it might be in sync with half a dozen endpoints, and it might be
interesting to distinguish them.
Zindus - Google and Zimbra contact sync for Thunderbird.
Would you ever want Thunderbird to collect email addresses from From
fields? You'd end up with a lot of rubbish, even from non-spam messages
We could probably fairly easily store the identity at which the message
was received. We could probably store the message id as well, such that
you could go back to the original message. Don't forget, that this will
just be messages you send.
> > - Sync
> The sync endpoint that generated the contact might make a useful
> attribute. For example, "created by Sync with mobile phone" or "created
> by sync with server blah". If Thunderbird is to play a role as a Sync
> Hub it might be in sync with half a dozen endpoints, and it might be
> interesting to distinguish them.
That I see no problem with, certainly the Sync items could store it
easily with the new architecture.
> We may want this to be a minimum of one writable book, but its
> probably not vital.
How would the collected address book ui look if no address books are
Warning: May contain traces of nuts.
Le 25/04/2008 11:30, Mark Banner a écrit :
> *Drop the Collected Address Book*
> With the status change above, and the improvement for white listing, we
> can then drop the requirement for the collected address book.
I'am very afraid by this dropping affair. Do you really talk about the
disappearance of the collected address book ?
1/ At work, we feed the collected address book (CAB) with addresses
within our sent mails. We also use a corporate ldap directory for
intranet mail addresses autocompletion but it is slower to respond than
local AB. As a user often have same addressees, CAB is used both as an
history and a pseudo ldap cache.
2/ With the autoconfig feature (aka MCD), we had defined standard
positions for our 2 ldap directories (prefkey:
ldap_2.servers.LABEL.position) in the thunderbird.jsc file, which values
are 3 and 4. Position is an important parameter because it permits to
fine recreate a directory entry accidentally deleted by the user within
the UI. Value 0 means dynamic position (default position), value 1 is
reserved for the PAB and 2 is for CAB.
Does your proposal (deeply) impact these kinds of use ?
We would have to disable it. In some cases, I suppose
enterprise/corporate folks may want just one read-only book (I think
they can force disable of collection now), though obviously that
wouldn't be much use for personal emails.
Disappearance of the collected address book from the list of address
books for new profiles (obviously we'll maintain it when migrating from
At this stage, I'm also not saying that you won't be able to create a
second address book.
However, you may have missed my point - that we could replace the
separate CAB with a way of tagging/labelling contacts. So you could have
one book with both collected and added contacts, and be able to tell the
difference - we'd probably also provide some ways of easily selecting
which ones to view.
> 1/ At work, we feed the collected address book (CAB) with addresses
> within our sent mails. We also use a corporate ldap directory for
> intranet mail addresses autocompletion but it is slower to respond than
> local AB. As a user often have same addressees, CAB is used both as an
> history and a pseudo ldap cache.
Well our LDAP implementation really needs upgrading to store a local
cache and use that (there's been a few mentions of this in various
discussion I've had off-line recently).
So as I mentioned above, you'd still be able to use (potentially just
the one) address book in the method you do currently.
> 2/ With the autoconfig feature (aka MCD), we had defined standard
> positions for our 2 ldap directories (prefkey:
> ldap_2.servers.LABEL.position) in the thunderbird.jsc file, which values
> are 3 and 4. Position is an important parameter because it permits to
> fine recreate a directory entry accidentally deleted by the user within
> the UI. Value 0 means dynamic position (default position), value 1 is
> reserved for the PAB and 2 is for CAB.
I didn't actually cover sorting in my post. What I would like to do is
to drop the current "forced" method, and implement something different.
However, I expect that a custom order would be useful (e.g. for
autocomplete), and therefore we'll probably maintain this in some form.
For your case, maybe the better solution would actually be to allow
disabling the deletion of address books via the autoconfig feature.
> Does your proposal (deeply) impact these kinds of use ?
Hopefully I've given you enough answers to assess this. I'll be
interested to hear further thoughts.
For your redesign of the TB/AB I would like to add the following comments:
at *Status Field/Indicator for source of Contact*
You have the 'Sync' included, but it would be wise to differentiate the
FinchSync -- an java standalone app working with SB/LG and TB/AB --
uses a concept with a combined id:
< server name>:<syncsource name>:<original category>
for details see http://www.finchsync.com/docu_syncguide.html
From my POV this is somewhat complex, but can help to track the source.
Also the point here is: FS is using a concept to handle different sync
sources. One contact belongs to a specific sync device, but also could
be configured to share also with others.
at *Minimum number of address books set to one*
The CAB has one advantage: current TB doesn't handle duplicate (well).
Normally I collect with CAB and have to manually phase new ones into PAB
with some pain. But I have a "clean" PAB ... most of the times.
Going with one AB NEEDS a good concept to find duplicates! There is an
extension, but requires also a lot work to clean it. Also it's only
working on ONE AB -- not comparing between ABs.
More points to optimize the TB/AB:
>> Current implementation doesn't support the "last modified" field.
Also here an extension can help, but there are operation which resets
that "time stamping" field. Eg. exporting or moving from one to another AB.
>> A *unique stamp for each AB card* would be very helpful:
==>> to be used to access a certain address card from other app/xpis
(fe. to access it from eg. ReminderFox or other productivity tools)
>> A *change history for the AB card* would be great!
See also bug 413260, where such an identifier will be added to cards and
all address book items in general. With the caveat that the uuid is only
guaranteed to be unique within the source directory, so that only a
directory.uuid+'-'+card.uuid will be truly unique.
I understand from bug 413260 with next vers.TB there will be an UID ..
for each card. EXCELLENT!
From looking around about the new AB I didn't finally understood if the
CATEGORIES item  will be implemented too?
As you know Paolo has supported this since sometimes with his great XPI
 MoreFunctionsForAddressBook. But it would be very helpful for
compatibility with other office productivity tools to have it supported
on a standard TB level.
That is more likely to be implemented in tag form than categories, but
the two would probably be compatible.
We haven't yet really discussed tags, I'm waiting on being a little
further along with the back end rework before I think about that too
much, as we'll need at least some of the changes to make it feasible.
I'm keen to have a common concept for it across all TB features
(messages, address cards, extensions etc ..)
Thanks, could you please give some pointers for :
-- with TB3.0 nightly is the UUID per card already implemented ??
-- is a migration required with old AB's/cards to the new concept??
-- if migration, does it automatically add an UUID, or will it be added
only with an changed card??
Imported to me to be able to start early with some XPI
-->> can you give some references how to use that
For example: is it possible to access a card directly using the UUID?
-->> is the "LastModifiedDate" item for each card supported on a general
basis with TB3.0 also ?? Or will it be used only/exclusively with Palmsync??
There isn't one yet, we're waiting for the patch to be reviewed.
> -- is a migration required with old AB's/cards to the new concept??
No migration, its exposing existing data.
> -- if migration, does it automatically add an UUID, or will it be added
> only with an changed card??
> Imported to me to be able to start early with some XPI
> -->> can you give some references how to use that
> "directory.uuid+'-'+card.uuid" ??
Note that the directory uuids may be changing, I've still got to look at
how that will work yet, at the moment I'm waiting on getting the current
changes in to make the picture a bit clearer.
> For example: is it possible to access a card directly using the UUID?
Currently it is not possible. In the future, maybe.
> -->> is the "LastModifiedDate" item for each card supported on a general
> basis with TB3.0 also ?? Or will it be used only/exclusively with
I'm not sure PalmSync actually uses LastModifiedDate. If we do have
this, I expect the current one may have to change as I am fairly sure we
have no sense of timezones currently.
So unfortunately this is pretty much all WIP. The uuids in cards I hope
will appear in the next week or so.
The "LastModifiedDate" is a system that is mostly based on trust, but I
think that most places within the address book itself do correctly set
it, modulo date issues.
There is also Bug 321269 – date and timestamp address book card entry
when added and changed and allow sorting by date
>> For example: is it possible to access a card directly using the UUID?
> Currently it is not possible. In the future, maybe.
Thought to have a programmatic call to be used within an XPI. Hope to
get that. Will it??
>> -->> is the "LastModifiedDate" item for each card supported on a general
>> basis with TB3.0 also ?? Or will it be used only/exclusively with
> I'm not sure PalmSync actually uses LastModifiedDate. If we do have
> this, I expect the current one may have to change as I am fairly sure we
> have no sense of timezones currently.
With the MoreFunctionsForAddressBook" [*] written by Paolo the
LastModifiedDate is displayed on a card tab. That works pretty well. But
there are some actions which will reset it. (Export, move to another AB,
> So unfortunately this is pretty much all WIP. The uuids in cards I hope
> will appear in the next week or so.
Can you please post for this? or drop a line??