##

Reviews for pap290
Decision: reject

Reviewer: | #1 | #2 | #3
Relevance: | 8 | 5 | 7
Tech. Soundness: | 7 | 6 | 6
Tech. Importance: | 3 | 6 | 2
Originality: | 3 | 5 | 8
Presentation: | 7 | 7 | 7
Overall: | 4 | 7 | 3
Recommended Action: | WEAK REJECT | WEAK ACCEPT | REJECT
Comments: | see below | see below | see below

Reviewer #1's Comments:
The paper describes a library intende to privide scientific applications with a Web interface. Use of the library allows an application to be monitored and controlled using a Web browser with minimal change/disruption of the the exisiting application code base. This SWILL library appears to be a useful tool for leveraging Web browsers to monitor and control scientific applications. However, beyond the idea of pckaging a Web server as a library that intercepts standard I/O functions and redirects the outpur to a Web page, there is not a lot of novelty and technical substance in this paper.

Reviewer #2's Comments:
The paper is interesting although I am surprised that something equivalent to SWILL does not exist already. The figures and tables were very useful.

Reviewer #3's Comments:
The paper outlines SWILL -- a scheme for attaching a web browser to a running scientific application and using the browser as an output terminal. To do so, the application must be made to respond to HTTP requests and to format the application's output accordingly. The paper describes, by example, how MPI programs (written in C) can be modified to field HTTP requests and use the requesting socket as an I/O device. I certainly found this paper entertaining. The idea of turning running MPI programs into web servers is a novel one, to be sure, however it isn't clear what problem, exactly, this implementation strategy solves. For example, it is common for scientific applications to produce "snapshot" files that get overwritten, periodically, according to where the snapshots are taken in the code. Often, these files are ascii text or HTML so that they can be easily and quickly examined with a web browser. By dumping the output directly to a socket (as opposed to into a file), the application might save the file space used for the snapshot, but it isn't at all clear that this snapshot space in a problem. Furthermore, since the SWILL model requires polling for incoming requests, output can only be generated at certain points in the program's execution -- that is, at certain snapshot points. Since the methodology seems equivalent to simply outputting data to overwritable files and then viewing these files with a browser (I've even used HTML refresh and server push in these cases), and since there is no clear resource or implementation problem this technique seems to overcome, I do not recommend this paper for publication.