* this is only a draft, so it's not written according to the GNU GSoC template. When discussion is done, I'll get a formal one done (with schedule etc.) *
Briefing ==== As is known, a new Python3-based test suite was implemented to replace the old one. And a configurable HTTP server utilizing `http.server` and `http.BaseHTTPRequestHandler` was also implemented. Thus the HTTP server can be configured to respond certain headers according to the configuration in separate test cases. However, a configurable FTP server was not required to be implemented, which breaks the consistency of the test suite of wget. So it's necessary that a configurable FTP server be built. Initial Design ==== The test suite consists of two parts: `WgetTest.py` (module that actually runs the tests), servers (configurable HTTP and FTP server). When running test cases, `HTTPTest` instances collect configurations from test cases and start the servers with them so that the HTTP handler will handle the incoming requests according to the configurations (also known as rules). About the FTP server, I think the handler architecture can be applied here: implement multiple handlers corresponding to the FTP commands and register them in server instances automatically. When registering handlers, the server should also inform the handlers about the configurations. When new FTP command arrives, the server invoke the corresponding handler, and then the handler look up the rules itself and do the expected actions. When doing real FTP actions, I intend to use third-party FTP library like the current FTP server (I fear sockets so best not directly touch them). There's two things that are unclear: * the necessity of implementing all the FTP command. I presume that wget wouldn't utilize all of them. * what will the configurations be, do I need to design the tests myself? Or should I also port the Perl scripts to Python3? Test Suite Refactoring ==== While reading source, I don't find the test suite pythonic. Multiple parts of it seems unmaintainable. If the test suite can be refactored into a better coded one, maintainability can further be achieved. Examples of unpythonicness: * docstrings out of classes or methods * mutable objects as default argument values * multiple use of operator is (controversial) * writing `_replace_substring (WgetTest.py:119)` instead of utilizing the format specification mini-language Examples of unmaintainability: * referencing attributes which are defined in subclasses (`WgetTest.py:61` references `self.servers` which is defined in its subclass `WgetTest.py:254`) * inappropriate variable names (in `WgetTest.py:254` `self.servers` actually becomes an integer while it regarded normally as a list of servers) * no intuitive, self-declarative module hierarchy About me ==== My name's Zihang Chen. I'm a 3rd undergraduate student from China (timezone: UTC+8). Please forgive me for any mistaken uses of the English language. I have been using Python for 3 years. I mostly code for myself (assignment, interest etc.) Never worked for any open source organizations before, so I'm thrilled to apply for GSoC. You can visit my GitHub page here<https://github.com/mad4alcohol> . Looking forward to your comments. Thanks very much. -- Regards, Chen Zihang, Computer School of Wuhan University --- 此致 陈子杭 武汉大学计算机学院
