Closed Bug 472494 Opened 16 years ago Closed 16 years ago

Thunderbird needs a FHS-compliant place to store addressbooks

Categories

(Thunderbird :: Address Book, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: razvan.sandu, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; ro; rv:1.9.0.5) Gecko/2008121622 Fedora/3.0.5-1.fc10 Firefox/3.0.5
Build Identifier: 

Hello,

IMHO, future versions of Mozilla Thunderbird needs a fixed (and well-documented) place to store the addressbooks in the host's filesystem. On *nix/Linux machines, this place should be chosen in strict FHS compliance (http://www.pathname.com/fhs/)

This would allow, more easily:

- developing programs for syncronizing Thunderbird addressbook with mobile phones (in Windows, like Nokia PC Suite or Motorola PhoneTools);

- addressbook backup/restore and import/export to vCard, LDAP, etc.;

- crossplatform applications (how about a free-software "Nokia PC Suite for Linux" or better integration with the company's intranet directory ?)

-  sharing/controlling access to addressbooks, system-wide and network-wide.


IMHO, on all platforms we easily distinguish two kinds of addressbooks:

- private - accessible to one user only;

- shared - that are accessible to many users on the network, in a client/server manner. A particular case is  "shared system-wide", where client and server reside on the same machine.

On Linux systems, the place for shared addressbooks should be chosen with SELinux-enabled systems in mind.


Regards,
Răzvan

Reproducible: Always

Actual Results:  
There is no  fixed, FHS-compliant place to store addressbooks, making difficult to write addressbook syncronization applications.


Expected Results:  
Such a fixed place should exist and be well-documented on all platforms.
Currently all of Thunderbird's Address Books are treated as private, and as such stored in the relevant profile directory on all platforms. We only support LDAP as a shared address book (though we do support Mac's Address Book, but that isn't really shared).

I'm not sure what you are asking for in this bug. So I'll address some of your comments:

(In reply to comment #0)
> - developing programs for syncronizing Thunderbird addressbook with mobile
> phones (in Windows, like Nokia PC Suite or Motorola PhoneTools);

We are currently exploring sync solutions for Thunderbird. I don't see how putting the address book in say /addressbook on all systems would help this. The current locations are well documented.

> - addressbook backup/restore and import/export to vCard, LDAP, etc.;

The data is stored alongside the profile directory, along with the rest of the data Thunderbird stores. It is consistent and well documented. Import and export is performed via the application.

LDAP servers store their data in their own location, we can't control that.

> - crossplatform applications (how about a free-software "Nokia PC Suite for
> Linux" or better integration with the company's intranet directory ?)

This would typically imply a location on a network share, or a specific location on a drive that the user can map between platforms. We can't force a specific location as there are too many custom set-ups to take account of.

> There is no  fixed, FHS-compliant place to store addressbooks, making difficult
> to write addressbook syncronization applications.

What applications are you trying to write?

> Expected Results:  
> Such a fixed place should exist and be well-documented on all platforms.

IMO its not possible to have one consistent fixed place due to the way windows works. The profile locations are well documented, for example here: http://kb.mozillazine.org/Profile and I know of a few others as well.


Having now gone through the comments, I really think you are asking for shared address books, which we don't currently support. Am I correct?
Severity: major → enhancement
Summary: [RFE] Thunderbird 3.x/4.x urgently needs a FHS-compliant place to store addressbooks → Thunderbird needs a FHS-compliant place to store addressbooks
Hello,

...and thanks for your prompt response.

I try to see things from a higher perspective than strictly technical, including Thunderbird's market acceptance and "politics".  ;-)

I'm not a programmer myself, but a system administrator. What I'm trying to do is to attentively observe the requirements of my non-technical users and to pass them to developers, "encoding" them in technical language. Of course, as a free-software/Linux strong supporter, I'll be HAPPY to help on the matter myself or to find local programmers that may do.


Some of the present *main* limitations of Thunderbird (and obstacles to wider adoption) are:
 
- no comfortable way of syncronizing the addressbook with a common mobile phone (as users do in Outlook), *independently* of SO/platform or phone model;

- no way to share addressbook information system-wide or network-wide (*easy* integration in a company's intranet directory, read/write);

- no easy way to share addresbook information with other devices or applications in a *standardised* format - vCard seems to be the best candidate. IMHO, the functionality provided by the MoreFunctionsForAB extension should be integrated in the core product...

The first question is how to treat the AB as a separate entity - *where* it is physically saved, how can you process it with *external* tools (access read/write, backup/restore, standardised file format, making the AB accessible by *other* e-mail clients than Thunderbird...). IMHO, a more modular approach would be in everyone's best interest.

Please imagine a system with 10 different e-mail clients installed ;-) , that all share the same addressbook, read-write. Please extend this at network level, via some platform-independent protocol (LDAP ?)...

IMHO, starting by deciding a *fixed* and *FHS-compliant* place for shared addressbooks, should be the starting point. For example, if it becomes common knowledge that the shared ABs stay in /srv/addressbook/ab1 ... /srv/addressbook/abN will allow SO developers to implement optimised permissions schemes, SELinux policy, firewall rules, etc. to access them.

Of course on Windows would be different, but we will acquire, at least, a common scheme in *nix-family an we can "mimick" this/adapt on other platforms.

The second step should be deciding a *standardised* (W3C? ISO?) file format for the AB. This is the basic condition for an API for external processing (like import/export, syncronizing with mobile phones, etc.). You said that "import and
export is performed via the application", meaning its interface - IMHO, this uniqueness in accessing the AB is one *serious* limitations (a bug, not a feature ;-) ).

I feel that a wider discussion on this matter, with many people (technical and non-technical) would let us understand better what users *really* expects. So *please* invite others to see and give their opinions on this.


Thanks A LOT,
Răzvan
Răzvan, are there any email clients now on the market that do what you say, or at least are very close to that ?
There is also the XDG standard at freedesktop.org for such things like directory locations.
In this bug, Răzvan is proposing a solution to multiple items, some of which we've already got on file, some of which we're soon going to be having discussions in the area of.

However the problem with this bug is that it is trying to look at the concept of how Thunderbird (and potentially other applications) operates rather than a specific instance of a problem within Thunderbird.

For this kind of concept of operation, we normally use discussion channels, in this case based around the newsgroup mozilla.dev.apps.thunderbird on news.mozilla.org, rather than bugzilla, because it is better for handling discussions.

Therefore I'm resolving this bug as invalid due to what it is trying to cover and would encourage you to move this discussion to the newsgroup. If we subsequently decide that it would be good (and where we want Thunderibird to go) for Thunderbird to implement shared / FHS compliant / other common formats etc then we can raise appropriate bugs for the specific implementation details.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
Hello,

As requested by Mark in comment #6, I've synthetised these ideas on a thread at mozilla.dev.apps.thunderbird, in order to continue the discussion about these general design principles.

Please see here:
http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_thread/thread/790fe3d4543d3b28?hl=en#

I invite all interested persons to join there and post their technical opinions on the matter.

Thanks a lot,
Răzvan
You need to log in before you can comment on or make changes to this bug.