[Note] 送patch所學到的事

這個Note是一個寫patch的經驗，前陣子寫了一個讓curl即時壓縮加密FTP/HTTP/SFTP上傳時可以續傳的一個patch，patch本身倒是沒什麼特別的，反而是在送patch跟原作者的討論過程中學到了一些東西。patch歷時約一個月才commit進cvs，不過我覺得以open source的專案來說，這樣算挺快的。

似乎還是得把前因後果交代一下，
其實一開始是我有一個想法，
就是希望我上傳到遠端伺服器的檔案都能加密起來(順便壓縮更好)，
但是我覺得在local這邊先壓縮過然後再上傳的話，就會佔Local的硬碟兩份空間，所以最好的方法是realtime壓縮加密之後上傳。這樣就不會佔用local的硬碟空間，而以目前的CPU也應該都可以做到即時傳輸。
此外我希望就是能夠彈性的選擇壓縮及加密方式，不論是bz2,gzip,pkzip或是pgp及AES都要能夠自行選擇及combine。
而且最好是不需另外的伺服器程式，以目前hosting都會提供的FTP帳號就能做的方法是最好。(我需要的不是像SFTP或FTP/TLS這樣傳輸時加密或壓縮而已，我想要的是在伺服器上的最終結果也是加密及壓縮過的)

跟lloyd討論之後，他是認為lftp+namepipe的方式可行。
另外我也找到了用pipe透過curl上傳的方法。
而這兩個方法也都驗證過確實可行，不過這兩個方法都同樣有個問題，就是沒辦法續傳，而這我認為是個應該要解決的問題。

比較了兩個解決方案後，我選擇了擁有我比較喜歡的BSD license，用法也比較彈性的curl下手修改，
curl的續傳問題大概長這樣：

gzip /mnt/2311/debian-500-i386-CD-1.iso -c | curl -T - -C -
ftp://myname:mypass@192.168.23.11/debian-500-i386-CD-1.iso.gz
** Resuming transfer from byte position 46792704
% Total % Received % Xferd Average Speed Time Time Time
% Current
Dload Upload Total Spent Left
Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
0
curl: (31) Could not seek stream

最主要是stdin不能直接SEEK_SET，這其實不是什麼大問題，不能SEEK_SET就SEQUENCIAL READ並bypass即可，看了一下原始程式便發現其實這段code早已大部完成了，只要略為更動即可，
於是略為修改了一下curl FTP/SFTP/HTTP上傳部份的code，驗證之後便將patch送出。
原以為送出patch之後就結束了，因為作者要收不收這也不是我能控制的，不過後來curl的作者回信說，功能是沒有問題，但原本的patch會影響到ABI與目前文件的相容性，問看看我是否能提供不修改ABI的作法，我原本還無法理會作者的意思，後來繼續討論才慢慢了解，作者的意思是看能否提供完整的ABI及定義回傳值供其他使用curl library部份的程式參考，因為curl不僅僅是一個客戶端程式curl，同時也包含一套廣泛的運用在其他程式甚至內建在程式語言中的library，libcurl。即使是改動小小的部份，也有可能不經意的影響到其他重要的程式。
了解了作者的目的之後，於是我又寫一個新的patch配合這個架構，測試一下續傳上傳沒問題之後就又再次的送出，這次作者將我的多個patch檔結合後又修改了一下包括說明文件的patch就直接commit到cvs上，不過問題來了，做make test的測試到HTTP PUT該項時沒過。
仔細的研究一下，還真的是第二次更動的code造成了問題。第三次的修改並驗證之後，這次就很快的patch就被接受了，目前已經commit在curl的cvs上。

這次寫patch得到一些經驗:

1. 寫patch時應配合原程式的架構及style，會比較容易被接受。
2. 寫完patch之後應照原程式的測試方式做一遍測試，而非只是測試自己的情況。
3. 大部份時候都要仔細考慮並聆聽來自原作者的意見，畢竟他是最清楚全部情況的人。
4. 不要懶的送patch，雖然可能會多費一些時間跟功夫，但送了patch通常可以學到更多。

ref: 我和curl作者討論的過程，https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2709004&group_id=976