Case-insensitive parsing of <id-right> in message-IDs

[Julien ÉLIE]

Hi Russ,

>> I am answering to an old message (December 2009) because someone has
>> just asked me why his 'XPAT References' calls are failing when the
>> message-ID that he looks up contains uppercase characters.  He notes
>> that when replacing the uppercase chars with '*', INN finds the article.
>
> That's weird.  The hash case insensitivity shouldn't be causing that.

Hmm, yes, you're right.
I have just asked for more information about the issue he reported.

I have tried with CURRENT and do not see any issue.


XPAT references 503 *<TESTv0a$3 at news.trigofacile.com>*
221 Header or metadata information for references follows (from overview)
503 <TESTv0a$3 at news.trigofacile.com>
.
XPAT references 503 *<tESTv0a$3 at news.trigofacile.com*
221 Header or metadata information for references follows (from overview)
.

The article is properly found with "TEST".  No need for "*".



>>    - ask in our release notes to run this script once, right after the
>> upgrade or after a run of news.daily.
>
> That's a good idea.  You could just run that script directly in
> innupgrade, even.

I fear it took too much time to run it.  Usually, innupgrade is supposed 
to be fast -- especially if the user stops his news server at that time.


Maybe we could just run makehistory at the end of innupgrade.  It will 
be the quickest fix.  I'm joking :)



>> Maybe the actions could also be integrated in expire, and therefore
>> directly writing the new history file in the right format.  We should
>> find a way to do the check only once, though.  Maybe by putting an
>> "expire.dohistconvertcase" file in pathlog at the end of a make
>> update. If present, expire does that and removes the file.
>
> Oh, possibly even a better idea.  Yes, I like that.
>
>> Yet, it will do that after every update.  Perhaps not a big deal for
>> official releases.  It is more problematic for people who frequently
>> update from STABLE or CURRENT.
>
> Maybe we can store somewhere in the database that we've done the upgrade?
> Really, ideally, we should have some sort of database version number that
> can indicate things like this.

Too bad just using "hisv7" instead of "hisv6" is not that easy.
Incidentally, do you remember were the previous hisv1, ..., hisv5 
formats were and how they were handled before the hismethod: parameter 
in inn.conf?

A database version number would indeed be interesting to have.  That's a 
nice idea.  It would be checked when history is (re)opened.  It would 
even allow a smooth transition because as long as the history belongs to 
an old version, the hash could still be searched in lower-case characters.

When you speak about keeping a database version number, is it something 
like a <pathdb>/history.version file that contains "1.0", "1.1", etc. 
or… a <pathdb>/history.format file that contains lines parsable with the 
new parser:
   tagged-hash: no
   case-sensitive: yes
   large-file: no
   hismethod: hisv6
   format: [hash, date, token]

Funny, extensible things possible to do afterwards with the history file!

-- 
Julien ÉLIE

« En France, on n'a pas de pétrole, mais on a des idées ! Alors,
   j'ai troqué ma deux-chevaux contre une deux-bœufs ! » (Raymond
   Devos)