Re: mhbuild and long header fields

2023-09-16 Thread David Levine
Phillipp, I've been using your header field folding for a few weeks and I 
really like it.  I think that it should be committed, it's big step forward.

One issue to resolve first: the References header field at the end of this 
message ends with:
 <16f13de3df80f62de768420a3cc3a2fe.phil...@bureaucracy.de>
  <14298-1693614066.188834@mIBq.BRD6.6M0V>

There's always an extra space in front of the Message-ID that was appended 
last.  Is that a relic of repl?  Or, should the folding code collapse multiple 
white space characters at the beginning of a line?

David



Re: some thought on m_getfld

2023-09-16 Thread David Levine
Philipp wrote:

> [2023-09-02 14:41] Ken Hornstein 
> >
> > I think you are thinking at the wrong scale.  The problem with m_getfld()
> > is not the interface, it is that it should not exist at all.
>
> Actually not quite, I think step by step. First get a good function
> parsing the fields. Then look how this function can be used to parse the
> complete header.

With a scanner/parser approach, I don't think it's necessary to consider
those separately.

I agree with Ken:

> > So this suggests to me that really in most cases the whole header should
> > just be read and then you get some accessor functions to get out the
> > headers you care about.

The nmh code for interfacing with GMail APIs (on the gmailapis branch) does
that.  It's in Python and needs some optimizing, but at least it's brief
and corresponds to the RFCs.

David