Re: [fetchmail-devel] Merge MAPI code things

[Yangyan L. <yan...@gm...>]

Hi Matthias,

Thank you for your warmhearted reply!

> congratulations on finishing the project. I haven't yet reviewed your code;
> how about your availability for collaboration on code refinements should I
> deem them helpful - could you work on that if issues arise during the merge?
I've tried to limit the change made to fetchmail's original code as
few as possible. So I think it won't be too hard and I am confident
of resolving the issues:-)

>
>
> With respect to the merge, the fetchmail trunk is currently out of date,
> unmaintained and disabled.
>
> My tentative roadmap is as follows (but not fixed, I welcome any
> suggestions for improvement)
>
> - release 6.3.9 from BRANCH_6-3.
>
>  Could you check (dry-run) if merging the BRANCH_6-3 changes since you
>  copied that branch when forking BRANCH_MAPI is possible without major
>  effort? If so, I'd appreciate if you could synch up with 6.3.9 before we
>  try the merge-to-trunk effort.
BRANCH_MAPI was synchronized up with BRANCH_6-3 now.

>
> - merge BRANCH_6-3 into trunk and dub it 6.4.X for the nonce
>  (this may mean to delete trunk and recreate it from BRANCH_6-3,
>   and redo changes from the BRANCH_6-3 branch point to the point where
>   trunk fell unmaintained - I'll see)
>
> - The manual page should at least contain pointers to README.mapi where
>  adequate. Something like "--protocol mapi" (fill in whatever you chose):
>  OpenChange support, see README.mapi for details.
Could you have a look at the README.mapi and suggest which way is
better: merge it into manual or add some pointers to the README.mapi
at appropriate places in the manual?

>
> - merge MAPI support into trunk, perhaps with code revisions as I review
>  code.
>
> - perhaps clean up trunk, open ends for trunk (not all of them are needed
>  for the merge):
>
>  + sink.c is a mess. It does something like RTTI and under-the-hood
>    behaviour switching for SMTP, LMTP and MDA. Now, with MAPI as fourth
>    sink => eek. It needs abstraction, much like the "--protocol" feature.
My code did not touch sink.c by now. If the abstraction will take
place, I will handle the MAPI part.

>
>  + protocol vs. authenticator messup. KPOP (if it deserves to live) and
>    APOP are by no means protocols, but are just POP3 authenticators.
>    Probably unrelated to your work.
>
>  + SSL configuration is an intransparent mess, hard to understand, with
>    several "automatic"s under the hood, that I'd like to clean up.
>    Requires changing rcfile format.
>
>    Does MAPI require SSL support in fetchmail?
>    If not, it's independent of your work.
SSL is not needed by MAPI. I've write code to bypass the SSL settings
if users configure SSL for MAPI.

Best regards!
Yangyan