Re: some thought on m_getfld

[Philipp]

[2023-09-02 14:41] Ken Hornstein <kenh@pobox.com>
> >I'm not sure if it's a good idea to start this topic, but it bugs me a
> >bit. Also as a disclaimer my view on this is highly influenced by my own
> >m_getfld variant[0].
> >
> >Because of the missunderstanding of when LENERR is used I have looked
> >at m_getfld.c and I see some problems with the interface and the
> >implemetation.
> >[...]
>
> First, my apologies for not contributing more on the discussion regarding
> header folding; my life has been busy as of late.  But I have some thoughts
> on this.
>
> 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.

> As you note, there's a ton of duplicated code when dealing with m_getfld().
> This has led me to believe that the number of programs that actually need
> a m_getfld()-style interface is close to zero.  I think programs tend to
> fall into two styles of header access:
>
> - One where they process each header field at a time (like the config file
>   parser).
> - One where they need to slurp in all header fields and then just extract
>   the ones they care about (I think this is the most common).

I would split up your second case in two:

 - One where all fields are read and processed, but some fields are
   processed in a special way (like post)
 - One where only some fields are needed (like pick)

> 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.
> [...]
> I realize that this is a larger project and if someone just wants to
> improve m_getfld() that is fine with me.

A function to parse the complete header would be nice, but as you
mention this is a larger project. The problem header parsing is required
everywhere in nmh. Implementing such a function direct would required to
either rewrite every m_getfld user at once or having two parser at the
same time.

So to separate this first improve the field parser and build a high
level API based on this parser. This way there would only one parse and
the single programs could be updated step by step.

> In terms of implementation, as you note header fields have a well-defined
> structure so honestly my preference would be to write a flex lexer to
> process header fields.

Because I have not that much experience with flex, I have handcrafted
my m_getfld. But using flex (and yacc) sounds like a good idea.

> But really I think there should be a higher level
> API to deal with header fields rather than have nmh code call m_getfld().

Some time ago I have started a getfields() function for this. This
function collect either all fields or the one specified by a filter.
When you are interested in it, I can share it.

Philipp

> --Ken
>