Re: [Fetchmail-users] fetchmail | Migrate config syntax to multiline modularity without english (#7)

[grarpamp <gra...@gm...>]

> well?

Gitlab has deployed a broken captcha system.

Fetchmail can preserve the single line mashup
if it likes to close that part of #7.
No, due to random structure of such lines, I seriously
doubt anyone is _parsing_ such lines in shell as a killer
of anything but their own sanity :)
 _creating_ such lines in shell is a bit more interesting,
but doesn't move modularity forward.


The more important issue and future that should not be
closed is the creation of a proper modular config and
operation abstraction for 7.x.

The concepts of polling, servers, accounts, which set
of server folders, and selecting fetchmail's downstream
pipes and filesystem, among other config things,
needs to be broken apart and out into separate stanzas,
that can contain various config options, stanzas are then
assembleable in permutation by the caller as applicable,
by reference to those labelled stanzas, into particular and
complete polls...

fetch -user janeC -server beeH -folders setA -into localwayB -polling paramT
fetch -user johnQ -server fooD -folders setS -into localwayG -polling paramL
fetch -user johnQ -server fooD -folders setP -into localwayR -polling paramL
fetch -label comboN -server bar4
fetch -label comboN -server bar2
fetch -label comboA
etc, ...

Where comboN is label made up of other labels from
the config, or of config options, that would make up the
remainder of a full specification.


Fetchmail cannot do this cleanly today without user writing fully
permuted numbers of separate full fetchmail configuration files,
and executing them in manner to keep fetchmail from interfereing
with itself. This management and non-linear combination growth
is not helpful to users or entities with more than a few accounts,
servers, etc.

This has been mentioned before over years, reference
is not at hand, see old archive / tickets for more on topic.


Further, enhancing modularity for 7.x may help fetchmail abstract
to be able to "fetch" "messages" from other messaging
systems by future contrib plugin protocols beyond imap / pop.