this is only a partial solution for reporting changes, but it's
adequate if the goal is merely triggering a bulk action, like
re-indexing the local store.
inspired by patches posted by Yuri D'Elia <wavexx@thregr.org>.
seconds are too coarse for what we intend. technically, centisecs would
be sufficient (and more honest, given that we prefer coarse timers,
which have only tick precision), but that's a somewhat untypical unit.
in the spirit of being liberal about what we accept.
this completely re-structures the header processing loop, with the nice
side effect of eliminating the gotos.
REFMAIL: 87bkyzhoov.fsf@curie.anarc.at
... instead of reporting conversion errors directly in copy_msg_convert().
this makes it easier to autotest properly.
this reverts bc15e571 in spirit, sidestepping the problem it tried to
solve instead.
don't print the status, as the user doesn't really care whether it's
NO or BAD. more importantly, "NO LOGIN failed" is a rather misleading
thing to report.
replace the "DOM-like" model with a "streaming" model, i.e., the tokens
are now immediately processed by stateful callbacks as they are found.
this avoids plenty of allocations and copies (though not of the message
contents, yet).
- short literals are now printed even with only -Dn.
this ensures that we see all parts of, for example, LIST responses.
we use xprintf() for that, so we don't mess up the -Dn output in case
the literal contains something unexpected (we don't care with -DN).
- omitted bytes are now indicated.
- missing trailing newlines are now "pretty-printed".
- long literals are now printed in chunks as we receive them. this
makes the output messier, but it's necessary for an upcoming change,
and, on the upside, we'll get better indication when the transfer
gets stuck in the middle of a message.
this introduces a "commit" callback to the xprintf kernel, to avoid
pointlessly assembling a temporary output string prior to printing it.
one could lift the buffer limitations by introducing a "segment"
callback instead, but that would slow down xvasprintf() due to the
higher callback rate, for no good reason.
so far we shifted down the buffered data only when we ran out of space.
however, that may cause chopping up the actual socket read, which is a
bad trade-off with avoiding a moderate-sized memmove. so try to keep
enough space for the anticipated read size.
note that this ignores the zlib path, as that always does full-size
socket reads into z_buf, and saving inflate() calls seems pointless.
- use more appropriate name for socket object
- localize some variable declarations
- denoise the code by using more local variables
- don't pointlessly do stuff when we're failing anyway
technically, we should have been doing that since the beginning, but as
there is IMAP4rev2 now, it might actually matter (in about a decade,
when servers start dropping backwards compat ...).
so far, we'd print only a generic message - except in two cases, where
the generic error would be preceded by a specific one. now we always
print a single reasonably specific message.
the callbacks took the current parsing position only to pass it on to
the next list parse. so instead, store it in the state, and have a
separate function for continuation.
include the literal's length into the command itself, so error messages
become clearer. the commands are initially built for LITERAL+, and are
"edited down" right before sending if necessary.
some servers consider attempts to APPEND too big messages to be BAD
commands, rather than just NO-worthy ones. so just pretend that we did
in fact get a NO, and carry on.
this was tested with gmail. if we run into servers that don't send the
expected response code, we will need to relax the condition.
otherwise the synching may livelock due to failing to schedule follow-up
commands, thinking the buffers are still full. of course, this is
relevant only for commands that failed early and thus didn't free the
payload right after submission already - which will be possible only
after the next commit.
we didn't check that the UIDs are adjacent, so we might have caught
not fetched deleted messages between two fetched messages below the
bulk load range.
checking adjacency of UIDs would make expunges in the bulk range (which
is likely to be full of holes) rather inefficient. so we use sequence
numbers instead.
this is admittedly a rather academical fix ...
amends 18225344.
try to purge sync entries based on which messages are *actually*
expunged, rather than those that are *expected* to be expunged.
to save network bandwidth, the IMAP driver doesn't report all expunges,
so some entry purges would be delayed - potentially indefinitely, e.g.,
when only --pull-new --push is used, or Trash isn't used (nor
ExpungeSolo, prospectively). so keep a fallback path to avoid this.
this is essentially the same as 'New', but for previously seen messages,
such as those that would have been instantly expunged (because they were
marked as deleted), those that we failed to store for some reason, and
already expired ones that are now flagged.
REFMAIL: CAOgBZNonT0s0b_yPs2vx81Ru3cQp5M93xpZ3syWBW-2CNoX_ow@mail.gmail.com
