On Sun, 05 Jul 2026 at 09:12:53 +0200, Oswald Buddenhagen wrote:
[Rearranged]
> given your contribution history so far, i have a strong impression that
> you're just playing with an AI agent and seeing what sticks. i do NOT
> appreciate that.
I have not and do not use AI in any part of the development process
(writing, debugging, documenting, etc.). In fact I like to take pride
in that I actually put in the work to develop rather than offloading my
thinking to a machine.
I take the time to read documentation and understand my tools. I do the
work to find and fix bugs. I actively reevaluate my approach when
relevant. I do _not_ blindly throw crap at the wall.
I understand well what I have written and why. You're welcome to test
my understanding if you wish. Please do if that will convince you, as I
do not appreciate being accused of mindlessly using AI.
> this patch doesn't actually fix this.
> instead, it abstracts the authentication process as a whole. as far as i'm
> concerned, this is simply an obfuscation layer.
The patch had two goals:
1) Un-intertwine the current two implementations.
2) Add the infrastructure to allow a third implementation.
The patch introduces an abstraction layer because I think that fulfils
both goals. Both current implementations are given in separate files,
and any new implementation can also be added with its own file.
> then it also rewrites (and bloats) the mechanism selection, for no apparent
> reason.
The current logic expects exactly two lists of mechanisms to take the
intersection of. By fitting this into a function that can be called
multiple times (imap_auth_filter_mech()), I wanted to allow the ability
to call it any number of times. This required rewriting the selection
logic to un-hardcode the expectation of having exactly two lists. This
is a benefit of such an interface: it allows more flexibility with its
use.
If you'd like an example use case, consider how mbsync currently only
uses user configuration files (~/.config/isyncrc). Many programs also
use a system configuration file (e.g. /etc/<name>rc) in tandem with the
user config file. If mbsync sometime decides to add support for a
system config file, managing the included auth mechanisms should just
involve another call to imap_auth_filter_mech().
Take care,
Seth McDonald.
--
E9D1 26A5 F0D4 9DF7 792B C2E2 B4BF 4530 D39B 2D51
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
