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.