If evolution used the same attributes (or at least similar) for the postal address as other address book/contacts clients, there would be no need for such a an option. If I were to assume that evolution wanted to add support for the more common address book/contact LDAP attributes (streetAddress, l, st, and postalCode) and at the same time maintain backwards compatibility with the use of homoePostalAddress, then there would only be two options. Either have evolution use both sets of attributes for the same information or provide an option for the user to choose which they would rather use.
Obviously, the first option wastes space in the directory, adds un-necessary overhead to the directory (LDAP) server, and most importantly pro-longs the end-user experience for searches and updates. The second option mitigates all of the issues of the first and enables users of a common directory infrastructure to access a the same postal information through all address book/contact clients including evolution. Brad On Mon, 2003-07-14 at 15:37, Gregory Leblanc wrote: > On Mon, 2003-07-14 at 13:02, Brad Diggs wrote: > [snip] > > Second, add a configurable option to allow an end user to > > specify which format that they would prefer to use. > > Well, a preference for this ought not happen. There are already more > than enough, and this one is pretty obscure, and I'm sure unnecessary. > Greg _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
