這個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