Re: Duplicate In-Reply-To entries in reply buffer

["Bashford, Donald" <Don.Bashford@stjude.org>]

I agree with all of this.  (My response to Kuzuhiro Ito's other
message a few minutes ago was before I read this one.)

-Don
At Tue, 24 Jul 2012 18:28:36 -0500,
Kazuhiro Ito wrote:
>
> I am still confused somewhat, so I wrote notes for my (hopefully our)
> understanding.
>
> This problem is related with some bugs and risky codes.
> Actual bugs are;
>
> 1-1. elmo-msgdb-get-message-id-from-buffer assumes buffer is narrowed
> to a message header, but actually it is called from unnarrowed buffer
> in some places.
>
> 1-2. We have multiple extracting methods for Message-ID and they can't
> extract from some valid header.
>
> Risky codes are;
>
> 2-1. elmo-field-body is an alias for std11-fetch-field.  FLIM has
> std11-field-body function which does not assume buffer is narrowed.
> The name of elmo-field-body is confusing.
>
> 2-2. The name of elmo-msgdb-get-message-id-from-buffer is confusing.
> It makes us to imagine this function extracts Message-ID from whole
> buffer, not narrowed region.
>
>
> I think it would be better we fix 2-1 and 2-2 at first.
>
> Fix (my opinion);
>
> 2-1. Create elmo-fetch-field by the same definition of elmo-field-body
> and obsolete elmo-field-body.  If there are misused elmo-field-body,
> replace them with std11-field-body.
>
> 2-2. Change elmo-msgdb-get-message-id-from-buffer not to assume buffer
> is narrowed.  If we need the same functionality of the current
> elmo-msgdb-get-message-id-from-buffer, create new function,
> e.g. elmo-msgdb-get-message-id-from-header.
>
> 1-1. Fixed by 2-2's fix.
>
> 1-2. David's refactoring is efficient.  As far as I tested, no major
> performance problem was observed except using lexical analyzer.  So,
> if I can customize to disable lexical analyzer in this part, the most
> strict method (such as the combination of lexical analyzer and strict
> regexp in [wl-en: 05189]) would be permissive.
>
> --
> Kazuhiro Ito
>
>

Email Disclaimer:  www.stjude.org/emaildisclaimer
Consultation Disclaimer:  www.stjude.org/consultationdisclaimer