From: Yangyan L. <yan...@gm...> - 2008-09-01 17:25:45
|
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. Best regards! Yangyan |
From: Matthias A. <mat...@gm...> - 2008-09-01 17:47:18
|
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 |
From: Yangyan L. <yan...@gm...> - 2008-09-07 11:38:28
|
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 |