On Tue Jul 17 2012 Roland Winkler wrote:
> When I looked into this, I had a disappointing surprise:
> 
> BBDB uses a "message cache" for caching the BBDB records associated
> with a message. I had made a silly mistake that made the cache
> ineffective in BBDB 3. Well, that bug was easily fixed. But with the
> cache being effective again, some fairly important other things are
> not working anymore.
> 
> - The message cache contains for each message those records that
>   have been recognized / created when the message was first viewed
>   in the MUA. If these were the records matching the recipients
>   (say, following a call of bbdb-mua-display-recipients), a
>   subsequent call of bbdb-mua-display-sender again displays the
>   recipients, because only those records are stored in the cache.
>   Not quite the expected behavior.
> 
> - Messages are identified in the cache via `assq' and "message
>   keys". VM uses a message-pointer and rmail uses an integer message
>   key that work fine with assq. Yet for gnus, BBDB 2 used the
>   function bbdb/gnus-get-message-id that returns the value of the
>   "Message-ID" header of a message as a string. For BBDB 3, I even
>   copied this idea for other MUAs... Yet strings don't work with
>   assq and all the caching fails.
> 
>   Here a simple work appears to be assoc instead of assq. Yet this
>   is slower than assq, and I have doubts that then all the caching
>   is still worth the extra coding effort (in particular, when
>   properly keeping track of senders and recipients).
> 
> So far, nobody noticed a bottleneck because of the broken message
> cache in BBDB 3. I am tempted to remove this feature altogether...
> (better suggestions welcome)

2012-08-09  Roland Winkler  <wink...@gnu.org>
        Remove message cache that was broken.  There were two problems
        with it.  The cache did not distinguish between records associated
        with the senders and recipients.  So if a call of
        bbdb-mua-display-sender was followed by, say, a call of
        bbdb-mua-display-recipients the second call also returned the
        senders.  Second, the cache used assq to identify message keys to
        operate fast.  Yet most MUAs only provide strings as message keys.

        * lisp/bbdb.el (bbdb-message-all-addresses)
        (bbdb-notice-mail-hook, bbdb-notice-record-hook): Fix docstring.
        (bbdb-message-caching, bbdb-message-cache): Remove.
        (bbdb-buffer): Remove cache flushing.

        * lisp/bbdb-mua.el (bbdb-update-records): Remove arg msg-key.
        Remove caching of records.
        (bbdb-message-get-cache, bbdb-message-set-cache)
        (bbdb-message-rem-cache): Remove.
        (bbdb-mua-update-records): Remove arg msg-key from calls of
        bbdb-update-records.

BBDB is available at
http://savannah.nongnu.org/projects/bbdb/
To check it out, use
git clone git://git.savannah.nongnu.org/bbdb.git

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/

Reply via email to