Hey all,<br>I would like to have your attention for a minute so as to present a proposal for a KDevelop plugin called 'Tendency', as my GSoC project proposal, the aim of which was to ease the development of networking applications and to provide a rigorous testing framework for the same. I waited a little time for some rustling on the kde-soc mailing list, but none happened, so tonight, I sat to develop a small mock GUI for the same, which would better help me explain what I want to do with this application.<br>
<br>Idea: I basically want to create a system which can send data over the network to an application which is being tested. Let's take the case where I am a developer who is making a small QOTD [Quote of the Day] server, which runs on HTTP. I make the server using, let's say the Qt framework. Now, using tendency, I can automate the process of sending requests to the server and receiving their response and analyzing their response.<br>
<br>Links to a screenshot of the mock-up of the application:<br><br><a href="http://i40.tinypic.com/v5k3kw.png">http://i40.tinypic.com/v5k3kw.png</a><br><br>How it works: Please refer to the screenshot I've provided in the links above. Firstly, I select the 'HTTP' from the list of protocols. Each protocol that I select has it's own 'Datagram Editor' as you can see for HTTP below. Then, I select if I want to send the data over the network to an external address. If unselected, the data is sent over the loopback address [or the localhost]. One can also select the port the data is to be transmitted on. The third option which says, 'Transmit data after [2] seconds of starting debugging', is basically to auto-trigger the sending of data. A small delay is provided for the server to be setup and running. One can also uncheck it and transmit the data manually if she/he prefers. Next, I can select the sending method of the data [POST or GET] and then change the variables of POST and GET. The 'Variable Editor' opens a small dialog with which one can edit the various variables. The next option is to send any files if needed over POST. Thirdly, we can edit the body of the HTTP request directly. One can use it to not only test servers, but also clients. And, in the final section, one can edit the headers of the HTTP message.<br>
<br>What I propose further:<br>1. A framework to automate these tests and to provide a way to write unit tests for the same.<br>2. A system to analyze the response of the sent request, or to listen on a port for sometime and analyze the received data.<br>
3. A proper header editor, where one can edit the headers properly. By proper, I mean that for a header like 'Date', one can select a date from the calendar.<br>4. For TCP/IP and UDP [or Raw] network data, the following framework is proposed by me:<br>
<br>Raw network data can be thought to be made up of fields. In tendency, the Datagram editor for TCP/IP and UDP shows a list of fields. For example, in a custom implemented protocols, one may have the fields:<br><br>a. A [size] field: Specifying the size of the entire message.<br>
b. A [magic_numbers] field: Push in some magic numbers required by the protocol<br>c. A [custom_data] field: A field of binary data<br>d. A [metastring_size] field: A field specifying the size of the succeeding metastring_size<br>
e. A [metastring] field: A final string for some purpose.<br>f. A [checksum] feld: An md5 checksum of the entire datagram.<br><br>In the Datagram editor, the fields are shown as rectangles, and double clicking any of the rectangles opens up a dialog where one can select from the following options:<br>
<br>1. size : Size of the field<br>2. contents : Contents of the field<br><br>Although pretty straight-forward, tendency aims to make this process as comprehensive as possible. Tendency uses a concept of 'filters' to modify data present on other mediums, like the hard disk for example. Using this dialog, one could set the following options for the above mentioned fields:<br>
<br>a. [size]: size: 4 bytes<br>           contents: sizeof(__datagram)<br>b. [magic_numbers]: size: 6 bytes<br>                    contents: 0xBF 0xF4 0x56 0x7C<br>c. [custom_data]: size: /dynamic/<br>                  contents: fromfile('/usr/bin/a.out')<br>
d. [metastring_size]: size: 4 bytes<br>                      contents: sizeof(metastring)<br>e. [metastring]: size: /dynamic/<br>                 contents: '--//x-metastring-broadcast//--'<br>f. [checksum]: size: 32 bytes<br>
               contents: md5(fieldRange(size, metastring))<br><br>In the above example, some fields were pure constants, whereas some fields depend on other fields for their content. I have tried to give as many examples as possible. If you so wish, I would love to provide you with more details. Please give me your comments and any suggestions that you may have. I shall await your reply.<br>
<br>Regards,<br>Rohan Prabhu<br>