MailNews:Address Book RoadMap: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Move roadmap type items from the main address book page to one of thier own.)
 
No edit summary
 
(53 intermediate revisions by 3 users not shown)
Line 1: Line 1:
This isn't detailed, nor does it have timescales, nor has it been agreed between developers, it is more where we currently appear to be heading in the short term. Eventually, if we get some more active support, we may be able to improve it a bit more.
{{Template:Mailnews Address Book Resources}}


== Work In Progress ==
{{Template:Outdated|See the [[Features/Thunderbird|Thunderbird Feature]] pages for more info, and the [[Features/Thunderbird/Modern_Address_Book|feature page for address book update]]}}


* Drag and Drop fixes ([https://bugzilla.mozilla.org/show_bug.cgi?id=35837 bug 35837] & others).
__TOC__
* Tidy up and rework of the address book preferences/settings backend - [[User:Standard8|Standard8]].
** This will give us a more flexible back end that will make it easier to add new types of address book.
** This includes:
*** removal of redundant code.
*** removal of duplicate code/optimisation of existing code.
*** possible moving of pref backend functions from nsDirPrefs into the classes that define the directories themselves as this would be more appropriate.
*** finally the removal of the nsDirPrefs code.


== Short Term Goals ==
The purpose of this page is to provide a guide to where various aspects of Thunderbird/SeaMonkey may proceed to improve the address book and the various advantages of each step.


* Address Book autocomplete transfer to toolkit.
'''This is not an agreed roadmap, nor is it a statement of what Thunderbird/SeaMonkey will definitely do.'''
* Basic vcard redesign work - [[User:Mhovis|Mhovis]]
** Expand contact database to include a superset of all supported protocols / card versions, including sync tokens.
** Provide a framework to allow third-party protocols bi-directional interaction with a persistance abstraction layer for the contact database(s).  This would possibly use a network of contact observers.
** Each consumer of the framework would implement a "view" of the abstracted contact persistence layer, adding columns and interfaces to the persistence layer if needed.
** Translations between the different "views" would have to be considered if inputting from one interface and outputting to another (in essence using the persistence layer) is not sufficient.
** Possible relevant link libvcard? http://freshmeat.net/projects/libvc/


== Medium Term Goals ==
== Short-term Planning ==


* Relayout the new/edit card dialogs.
=== Active ===
** This would be to solve our current screen size issue,
** And would also be in preparation for the addition of more fields.
** [[MailNews: Address Book Card Fields]] - what fields do we want?
* Writeable LDAP address books.
* A possible new backend for the address book, see [[MailNews:Address Book Native Formats]].


== Long Term Goals ==
Note: Priority is current priority, not overall priority for TB 3.


* Pluggable address books
{|class="fullwidth-table sortable"
** A system whereby extra definitions for different formats/address book interfaces may be bolted onto the main address book code without need for major code rework. (things to remember: device synchronisation)
! Ref !! Item !! Priority !! Bug !! Who !! Target Milestone
* Device Synchronisation Interfaces
|-
** See [http://wiki.mozilla.org/Mozilla2:Device_Sync Device Sync]
| 1 ||height="25px"|Examine making Local autocomplete use directory search, rather than get all cards and manually work it out. || P3 || {{bug|450134}} || jcranmer? || 3.0RC1
* Some kind of generic interface for import/export etc of different types of cards and books.
|-
* Extension of formats that we interface to: [[MailNews:Address Book Interface Formats]].
| 3 || Create a new mailing list implementation class derived from nsIAbCollection. || - || - || - || -
* Better Handling of Large Searches in Address Book [[MailNews:LDAP and Large Searches]].
|-
| 3a || Part 1: separate out mailing list specific functions into js class from nsIAbCard/nsAbCardProperty. || P4 || ? || jcranmer? || 3.0b1?
|-
| 3b || Part 2: separate out mailing list specific functions from nsAbDirProperty into the new class created in step 1. || P4 || ? || ? || 3.0b1?
|-
| 4a || Fix Address Collection to use it (i.e. check all local directories for existing cards/addresses) || P2 || {{Bug|58769}} || Standard8 || 3.0b1
|-
| 4b || Remove external usages of nsIAddrDatabase's cardFromProperty || P2 || {{bug|451844}} || jcranmer || 3.0b1
|-
| 5 || Try to disentangle nsAbCardProperty from Palm Sync, so that the extension just uses the idl interfaces. || P4 || ? || ? || ?
|-
| 9 || Implement js tree for address book list pane instead of rdf one || P3 ||| {{Bug|422845}} || jminta? || 3.0b1
|-
| 11 || Revised Mailing List UI || P3 || ? || ? || 3.0b2
|-
| 12 || Tag implementation (needs design) || P2 || ? || ? || 3.0b2
|-
| - || New/Edit Card Dialog || - || - || - || -
|-
| 13 || [http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_thread/thread/56b70f0758cd5caa# Name restructure] || P3 || ? || ? || 3.0b2
|-
| 14 || [http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_thread/thread/93781d0b5c83edd8# Address restructure] || P3 || ? || ? || 3.0b2
|-
| 15 || Multi-valued fields (needs design) || P3 || {{Bug|118665}} || ? || 3.0b2
|-
| - || Other || - || - || - || -
|-
| 17 || Complete Writeable LDAP || P4 || ? || ? || ?
|-
| 18 || Async interfaces for remote directories || P2 || ? || ? || 3.0b2
|-
| - || Other items as listed below || - || - || -
|-
| 19 || Address book rename-a-thon || P2 || ? || jcranmer || 3.0b2?
|}
 
=== Completed ===
 
{|class="fullwidth-table sortable"
! Ref !! Item !! Bug !! Milestone
|-
| 8 || Implement xbl driven Address Book menus instead of rdf ones || {{Bug|449260}} || 3.0a3
|-
| 6 || Move cardForEmailAddress from nsIAbMDBDirectory to nsIAbDirectory || {{Bug|449618}} || 3.0a3
|-
| 7 || Fix Search/Filters for OS X Address Book (dependent on SP6) || {{Bug|437908}} || 3.0a3
|-
| 4 || Move cardFromProperty from nsIAddrDatabase to nsIAbCollection. || {{bug|450149}} || 3.0a3
|-
| 16 || Birthday Fields || {{Bug|13595}} || 3.0a3
|-
| 2 || Create an empty nsIAbCollection, inheriting from nsIAbItem and inherit nsIAbDirectory from it. [[MailNews:Address_Book_Interface_Redesign#nsIAbCollection|nsIAbCollection design]] || {{bug|450917}} || 3.0a3
|-
| 10 || [[MailNews:Address_Book_New_Card_Inline]] [[http://clarkbw.net/designs/msg-reader/std-msg-reader-w-expanding-headers.html]] || {{Bug|450724}} ||  3.0a3
|-
|}
 
== Back-end Interface Re-organisation ==
 
Design: [[MailNews:Address Book Interface Redesign]]
 
Main bug is {{bug|413260}}. An up-to-date tree, containing patches awaiting review or check-in, can be found at [http://hg.mozilla.org/Pidgeot18_gmail.com/ab_rewrite].
 
Current Steps (based partially on jcranmer's patch queue):
 
# <strike>Make the nsIAbCard interface more flexible for new properties and different types</strike>
# <strike>Move cardForEmail from Mork specific code to generic code {{bug|449618}}.</strike>
# Start refactoring nsIAbDirectory into nsIAbCollection (Partial Ref SP2).
# Implement the propertiesChrome function for opening AB property dialogs
# Separate mailing lists from directories and cards into their own object (Ref SP3).
# Move nsIAddrDatabase-specific functions to nsIAbCollection or nsIAbDirectory
# Decide on interfaces for address book interactions and compatibility with async/sync address books.
# Implement new interfaces from previous item.
 
Advantages:
 
* New interfaces will make it much easier to interact with the address book.
* Interfaces are designed to make interfaces generic across different address book types. They should hide the fact that you're talking to a LDAP book, or an OS X directory.
* Prepares for moving to SQLite.
 
Current Status:
 
* Patches in progress.
* Directory-related refactorings are still not fully defined.
* Standard8 needs to find time to discuss async/sync interfaces with dmose in more detail.
 
== Writable LDAP ==
 
Very much wanted by lots of people.
 
{{Bug|86405}} is the main tracking bug.
 
Current Steps:
 
# Once AB Interface redesign has completed the async/sync interfaces, implement appropriate hooks for LDAP (if not already there).
# Implement any required UI tweaks/improvements.
 
Advantages:
 
* Provides a good solution for users (mainly corporate/small networks?) to share address books.
 
Current State:
 
* Writable LDAP source code is in cvs, enabled by compilation switch.
* UI is no where near usable by end-users or advanced users (i.e. don't even think about it to be enabled by default).
 
== Remove RDF from the Address Book ==
 
Being able to do this partially depends on the interface back-end redesign, but will also help that.
 
Current Steps:
 
# {{Bug|422845}} Replace RDF-driven address book tree with js one (waiting on jminta, busy until June).
# <strike>{{Bug|449260}} Replace RDF-driven menus with xbl based one.</strike>
# {{Bug|408613}} Re-use the new tree for other address book menus (including address book and LDAP preferences).
# Replace any other RDF instances (none?) or uses.
# Remove RDF from the address book, at the same time, replace the current preferences system with a new one (based more on flexibility of address book types). New system to be based in nsAbManager.
 
Advantages:
 
* Removes "obsolete" RDF interfaces from address book
* Tidies up a lot of code and removes some old items
* Different address book types could be fully implemented in extensions in javascript {{bug|424218}} (TB 3 blocker).
 
== Switch Mork to SQLite ==
 
See {{bug|382876}}
 
Current Steps:
 
# Modify code to use generic directory accesses where not already doing so (part of the interface reorg and {{bug|413260}} as well, see above)
# Create an SQL backend for addressbook
# Write a conversion to translate mork to SQL using a new morkreader {{bug|424446}}
# Remove the old mork code
 
Advantages:
* SQLite is much more widely supported by other tools than mork
* SQLite allows us to use mozStorage, which could increase our future flexibility
* Any proposed schema will be simpler than the current mork addressbook schema
 
Current status:
* The new morkreader is pending review.
* Initial work blocking on nsIAbCollection creation; full work blocking on mailing list sanity.
* The schema is not yet finalized, and probably will not be finalized until after the interface reorg.
 
== Implement providers for different address book card translations ==
 
Steps:
 
# Once step 1 of redesign (nsIAbCard) is complete, implement code to change providers.
 
Advantages:
 
* This would allow different card translations e.g. nsIAbCard to vCard/hCard etc.
* Extensions could add to the formats available.
 
Current Status:
 
* Standard8 knows what he wants to do to put this together.
 
== UI updates ==
 
* Standard8 driving:
** <strike>{{Bug|397811}} UI to Enable/Disable Mac OS X AB interface</strike> (Complete)
** Changing the default address books ([http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_thread/thread/0339393c59e2fc90# Newsgroup thread])
*** Probably be wrapped up into the rdf removal
* clarkbw driving:
** Names on address book cards ([http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_thread/thread/56b70f0758cd5caa# Newsgroup thread])
** Addresses on address book cards ([http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_thread/thread/93781d0b5c83edd8# Newsgroup thread])
** [[MailNews:Address Book New Card]]
* No owner/timescale:
** Photo on contacts ([http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_thread/thread/e269e037d911653e# Newsgroup Thread])
** <strike> {{Bug|13595}} Add Birthday Field, TB 3.0 blocker</strike> (Complete)
** {{Bug|63941}} New Card layout shouldn't assume high screen resolution (blocked by other UI rework?)

Latest revision as of 17:18, 16 April 2012

Resources
MailNews Homepage
Address Book Homepage
Roadmap
Help Wanted
LDAP Address Books
Code Structure
Bug Locations
Related Standards
Ambox outdated.png THIS PAGE MAY BE OUTDATED
This article is in parts, or in its entirety, outdated. Hence, the information presented on this page may be incorrect, and should be treated with due caution until this flag has been lifted. Help by editing the article, or discuss its contents on the talk page.

The purpose of this page is to provide a guide to where various aspects of Thunderbird/SeaMonkey may proceed to improve the address book and the various advantages of each step.

This is not an agreed roadmap, nor is it a statement of what Thunderbird/SeaMonkey will definitely do.

Short-term Planning

Active

Note: Priority is current priority, not overall priority for TB 3.

Ref Item Priority Bug Who Target Milestone
1 Examine making Local autocomplete use directory search, rather than get all cards and manually work it out. P3 bug 450134 jcranmer? 3.0RC1
3 Create a new mailing list implementation class derived from nsIAbCollection. - - - -
3a Part 1: separate out mailing list specific functions into js class from nsIAbCard/nsAbCardProperty. P4 ? jcranmer? 3.0b1?
3b Part 2: separate out mailing list specific functions from nsAbDirProperty into the new class created in step 1. P4 ? ? 3.0b1?
4a Fix Address Collection to use it (i.e. check all local directories for existing cards/addresses) P2 bug 58769 Standard8 3.0b1
4b Remove external usages of nsIAddrDatabase's cardFromProperty P2 bug 451844 jcranmer 3.0b1
5 Try to disentangle nsAbCardProperty from Palm Sync, so that the extension just uses the idl interfaces. P4 ? ? ?
9 Implement js tree for address book list pane instead of rdf one P3 bug 422845 jminta? 3.0b1
11 Revised Mailing List UI P3 ? ? 3.0b2
12 Tag implementation (needs design) P2 ? ? 3.0b2
- New/Edit Card Dialog - - - -
13 Name restructure P3 ? ? 3.0b2
14 Address restructure P3 ? ? 3.0b2
15 Multi-valued fields (needs design) P3 bug 118665 ? 3.0b2
- Other - - - -
17 Complete Writeable LDAP P4 ? ? ?
18 Async interfaces for remote directories P2 ? ? 3.0b2
- Other items as listed below - - -
19 Address book rename-a-thon P2 ? jcranmer 3.0b2?

Completed

Ref Item Bug Milestone
8 Implement xbl driven Address Book menus instead of rdf ones bug 449260 3.0a3
6 Move cardForEmailAddress from nsIAbMDBDirectory to nsIAbDirectory bug 449618 3.0a3
7 Fix Search/Filters for OS X Address Book (dependent on SP6) bug 437908 3.0a3
4 Move cardFromProperty from nsIAddrDatabase to nsIAbCollection. bug 450149 3.0a3
16 Birthday Fields bug 13595 3.0a3
2 Create an empty nsIAbCollection, inheriting from nsIAbItem and inherit nsIAbDirectory from it. nsIAbCollection design bug 450917 3.0a3
10 MailNews:Address_Book_New_Card_Inline [[1]] bug 450724 3.0a3

Back-end Interface Re-organisation

Design: MailNews:Address Book Interface Redesign

Main bug is bug 413260. An up-to-date tree, containing patches awaiting review or check-in, can be found at [2].

Current Steps (based partially on jcranmer's patch queue):

  1. Make the nsIAbCard interface more flexible for new properties and different types
  2. Move cardForEmail from Mork specific code to generic code bug 449618.
  3. Start refactoring nsIAbDirectory into nsIAbCollection (Partial Ref SP2).
  4. Implement the propertiesChrome function for opening AB property dialogs
  5. Separate mailing lists from directories and cards into their own object (Ref SP3).
  6. Move nsIAddrDatabase-specific functions to nsIAbCollection or nsIAbDirectory
  7. Decide on interfaces for address book interactions and compatibility with async/sync address books.
  8. Implement new interfaces from previous item.

Advantages:

  • New interfaces will make it much easier to interact with the address book.
  • Interfaces are designed to make interfaces generic across different address book types. They should hide the fact that you're talking to a LDAP book, or an OS X directory.
  • Prepares for moving to SQLite.

Current Status:

  • Patches in progress.
  • Directory-related refactorings are still not fully defined.
  • Standard8 needs to find time to discuss async/sync interfaces with dmose in more detail.

Writable LDAP

Very much wanted by lots of people.

bug 86405 is the main tracking bug.

Current Steps:

  1. Once AB Interface redesign has completed the async/sync interfaces, implement appropriate hooks for LDAP (if not already there).
  2. Implement any required UI tweaks/improvements.

Advantages:

  • Provides a good solution for users (mainly corporate/small networks?) to share address books.

Current State:

  • Writable LDAP source code is in cvs, enabled by compilation switch.
  • UI is no where near usable by end-users or advanced users (i.e. don't even think about it to be enabled by default).

Remove RDF from the Address Book

Being able to do this partially depends on the interface back-end redesign, but will also help that.

Current Steps:

  1. bug 422845 Replace RDF-driven address book tree with js one (waiting on jminta, busy until June).
  2. bug 449260 Replace RDF-driven menus with xbl based one.
  3. bug 408613 Re-use the new tree for other address book menus (including address book and LDAP preferences).
  4. Replace any other RDF instances (none?) or uses.
  5. Remove RDF from the address book, at the same time, replace the current preferences system with a new one (based more on flexibility of address book types). New system to be based in nsAbManager.

Advantages:

  • Removes "obsolete" RDF interfaces from address book
  • Tidies up a lot of code and removes some old items
  • Different address book types could be fully implemented in extensions in javascript bug 424218 (TB 3 blocker).

Switch Mork to SQLite

See bug 382876

Current Steps:

  1. Modify code to use generic directory accesses where not already doing so (part of the interface reorg and bug 413260 as well, see above)
  2. Create an SQL backend for addressbook
  3. Write a conversion to translate mork to SQL using a new morkreader bug 424446
  4. Remove the old mork code

Advantages:

  • SQLite is much more widely supported by other tools than mork
  • SQLite allows us to use mozStorage, which could increase our future flexibility
  • Any proposed schema will be simpler than the current mork addressbook schema

Current status:

  • The new morkreader is pending review.
  • Initial work blocking on nsIAbCollection creation; full work blocking on mailing list sanity.
  • The schema is not yet finalized, and probably will not be finalized until after the interface reorg.

Implement providers for different address book card translations

Steps:

  1. Once step 1 of redesign (nsIAbCard) is complete, implement code to change providers.

Advantages:

  • This would allow different card translations e.g. nsIAbCard to vCard/hCard etc.
  • Extensions could add to the formats available.

Current Status:

  • Standard8 knows what he wants to do to put this together.

UI updates

Retrieved from "https://wiki.mozilla.org/index.php?title=MailNews:Address_Book_RoadMap&oldid=420440"