Re: [fetchmail-devel] Merge MAPI code things

[Matthias A. <mat...@gm...>]

Yangyan Li schrieb:
> Hi Matthias,
> 
> I've finished the GSoC project "add MAPI support  for fetchmail, what
> can I do to merge/help merge it into fetchmail trunk?
> 
> I didn't update fetchmail's manual now, I write a separate
> ReadMe.mapi. I will merge the ReadMe.mapi into fetchmail's manual
> after I have some feedback on both the MAPI plugin and how to write
> the new manual for easy understanding.
> 
> I am always welcoming for opinions.

Hi Yangyan,

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?


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.

- 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.

- 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.

  + 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.

Feel free to ask further questions, make suggestions, whatever, and many
thanks for your work!

Best regards

-- 
Matthias Andree