Too much of Jack Twilley's post to respond to, so I won't quote.
If we are talking wholesale reforms here, we ought to move away from
the name being the primary index key first I would have thought, to
allow multiple identical names in the DB. This could also allow BBDB
to prompt for new record creation when a new address is seen or an
existing name. This reminds me, when it mentions name mismatches, it
could offer some way to remedy it (by adding an AKA perhaps).
Jack was suggesting a list of permitted address/phone locations - a
prescriptive approach will not suit many without becoming enormous
IME, so lets not go that way. Instead I though of something else
(which also has its limitations) - locations, e.g. home, work,
parents, etc. Within a location you could have an address, some phone
numbers, email address list, GPS waypoints if you want them.
>From this, I would like to see better tab-completion in Gnus To field
- if there are multiple locations or multiple addresses within a
location, then completion prompts you for which one you want, and if
you continue trying to complete on an already complete address, it
gives you the opportunity to change it. This also reminds me of the
idea a while back on the list to have an 'active' list of email
addresses (ones to which new mail may be sent) and 'dead' addresses
which only correspond to historic mail.
If we are going to do PGP key storage, it must be a list to match any
email address list as there may well be different keys associated with
different addresses.
I would like cross-referencing. I have a number of correspondents who
are partners of/share a house with another person in the DB. It would
be nice to be able to ensure that any address/phone number change is
common to both.
Another desirable would be better control over the presentation of
elided responses.
I am not in a position to expect any of this to be listened to given
that my only code contribution to date was the net-allow-redundancy
patch (about 8 lines ISTR, and a couple of years ago), and see no
prospect of that increasing in the near future, but I have thought a
lot about what BBDB lacks over the years.
Pete
--
Peter Riocreux, Amulet Group, Dept. Computer Science, Manchester University,
Oxford Road, MANCHESTER, M13 9PL, UK. <http://www.cs.man.ac.uk/amulet/>
Voice: +44 161-2753547 Mobile: +44 7970-611366 Fax: +44 161-2756236
_______________________________________________
bbdb-info mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/bbdb-info
