Subject: CCPE Portal C532 From: Keith Moore Date: Thu, 06 Dec 2001 13:48:05 -0500 To: gcf@indiana.edu CC: moore@cs.utk.edu, dongarra@cs.utk.edu X-UIDL: g70"!@kK!!SRl"!9,T"! X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from grids.ucs.indiana.edu (localhost [127.0.0.1]) by grids.ucs.indiana.edu (8.10.2+Sun/8.10.2) with ESMTP id g011Ba618943 for ; Mon, 31 Dec 2001 20:11:36 -0500 (EST) Resent-Message-Id: <200201010111.g011Ba618943@grids.ucs.indiana.edu> Replied: Sat, 15 Dec 2001 21:58:32 -0500 Replied: Keith Moore Delivered-To: fox@csit.fsu.edu Received: from snorkel.uits.indiana.edu (snorkel.uits.indiana.edu [129.79.6.186]) by mailer.csit.fsu.edu (Postfix) with ESMTP id C920523A1C for ; Thu, 6 Dec 2001 13:48:09 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by snorkel.uits.indiana.edu (8.10.1/8.10.1/IUPO) with ESMTP id fB6Im7V10937 for ; Thu, 6 Dec 2001 13:48:08 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id fB6Im5T22845; Thu, 6 Dec 2001 13:48:05 -0500 (EST) Message-Id: <200112061848.fB6Im5T22845@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <22817.1007664426.0@astro.cs.utk.edu> Sender: moore@cs.utk.edu Resent-To: ccpe Resent-Date: Mon, 31 Dec 2001 20:11:36 -0500 Resent-From: Geoffrey Charles Fox X-UIDL: g70"!@kK!!SRl"!9,T"! Per your instructions, I have enclosed a) PDF version of revised paper b) Text response to referees' comment Keith Moore Here are our responses to reviewers' comments: > Referee 1 ******************************************* > > This paper discusses Netbuild, which is a tool that can automate the > processing of installing and configuring software libraries. Netbuild > works on heterogeneous platforms. The paper describes the basic > architecture of Netbuild and the initial implementation. > > As a software tool, Netbuild would be a welcome and useful addition to the > application programmers toolbox. Programmers spend an inordinate amount of > time searching for and installing software libraries. Such searches and > installations are often met with frustration as most such libraries do not > install, nor are correctly configured in an easy manner. If Netbuild could > overcome such frustration, it would be a truly useful software tool. > > Details in the paper are "light". The outline that is presented of > Netbuild seems reasonable. > One thing I couldn't quite figure out if there > were any language dependent issues? Will Netbuild work for C++ software > libraries that extensively use templates? What about mixed language > software libraries, will Netbuild install and configure different languages > equally as well? > Because the paper discusses an "initial implementation", it is difficult to > assess Netbuild's effectiveness. It would be great if the authors could > update the project to include any initial results. > Referee 2 ******************************************* > > E: Referee Comments (For Author and Editor) ------------------ > > Claims in the paper like "In General the more libraries on which a > program depends,t he fewer environment it can run on" are largely > unsubstantiated though understandable. There is no data given > substantiating such claims. E.g. I ran in to problems where a > program consisted on a large number of libraries 10 and it was more > portable that a program that was only dependent on one library. > The point I believe one needs to make is that portability > statements must be derived from the libraries. We were trying to make a statement about the administrative difficulty of installing large numbers of libraries on platforms that are maintained by different sets of people, not about program portability in general. We have reworded this statement in an attempt to make this clearer. > In Section C. Describe more about the efforts that are underway. > > Also the section implies that Net build is not stable, which would > be bad for this journal issue. NetBuild is definitely still a work in progress. For now, the collection of NetBuild libraries is maintained "by hand". Our experience with this kind of maintenance in the context of other projects - where the libraries were manually downloaded - has demonstrated that it is not adequate to serve users' needs. We do not wish to make NetBuild generally available until we can continuously maintain its libraries. We are awaiting funding for Netlib which will allow us to do this. > Section Searching for local libraries > > It is not clear who one deals with dependencies in > dynamically linked libraries. > > assume I compile a dependent on b with X > and b is compiled with Z that is incompatible with X > can that be done? We tried to make this clear in the Goals section of the revised paper. Netbuild cannot remove incompatibilities between different libraries. At best it can recognize them via its constraint expressions. > The attributes introduced in section "Identifying target ..." > imply that a weight must be imposed on this attributes, probably to > build a weighted sum. No analysis is provided on what would be > best, if this is a good idea, or whay and whay not certain > attributes are chosen. We did not make this very clear in our original submission, but we were not using weighted attributes. Also, we have changed the candidate selection algorithm since writing the original draft. Our revised submission reflects the current candidate selection algorithm, and provides an example of constraint expressions for several different implementations of a library. > The use of cgi and a global database may not be such a good idea, > as it causes a lot of delay. Why not define a service-based on other > more advanced technologies. later in the paper this is displayed as > a good part, but it seems to me this is more a "hack" than real > motivation. We tried to address this briefly in the revised version by stating that multiple servers are possible and the client is capable of choosing from several search engines. However, this technology is not specific to NetBuild and describing it at length would detract from this paper. > What short comings does the tar format have, no explanation is given. We could have listed them, but again, this would detract from the message of the paper. Since we are discarding the tar format anyway, we decided to just rewrite that section to avoid mentioning it. (in a nutshell, the chief benefit of using tar is the ability to use existing tar commands to assemble libraries by hand. however there are multiple versions of tar with slight differences between each, and we would have to provide tar extraction code to work with each of them. it would be difficult to be sure that we had covered all of the variants. also, using the target system's tar command to extract files introduces security holes, since on many systems tar files can specify complete path names, or relative path names, which could cause existing files to be overwritten. ) > Section NetCompile: > > How can I express the dependencies of the application for a > particular target platform. General statements are made, > but they are not substantiated with an example or a better > explanation. we supplied an example in the revision. > Section Distribution ... > > How can one prevent malicious libraries, wouldn't every > library need to be signed? yes. but netcompile does sign the libraries. > Section Related Work > > A more precise description of what you want to "borrow" is > in order. how should we say that we have looked at their code, and gleaned ideas from it, but not copied it? instead in the revised draft we just mentioned their work as related work without saying we borrowed from it. > Section Status ... > > we would like to see a discussion about the various > data models. Unfortunately, this is not described here. we should not have described this as "various data models"; rather, it is a single data model (per-platform) that we are developing and modifying based on our experience. we've reworded this in the revision. > Apply the technology to at least one other code example not > just Netsolve ??? not sure what he/she means by this, since we didn't mention netsolve. > F: Presentation Changes > > all over: > > During the print the following errors were obvious a , is > followed always by the next letter and a blank e.g. Internet,a > nd instead of "Internet, and" our guess is that this is a problem with fonts on the reviewer's system. we haven't observed this when viewing the document with either acrobat reader or xpdf. > Section D. > > A diagram necessary to explain architecture/usage. two figures and accompanying text have been added to explain this. > Section 3. paragraph NetBuildTool. > > This whole paragraph needs rewriting. The explenation of shims > could be better we have supplied a figure and text to illustrate the operation of the shims. > Section 3. General > > It is not clear if the information is stored in a global > directory or not. this should be clearer now with the additional text in section 3.1. > Section "Authenticaticity ..." > > Do not use a colloquial phrase such as the sentence with > "okay" in it this is not very precise language for an > academic paper. this has been reworded. > Referee 3 ******************************************* > > > Referee Comments (For Author and Editor) > > NetBuild builds on the successful repertoire of tools that have been > developed > at the University of Tennessee. It automates many of the tedious details > that > are involved in remote access of software libraries. > However, the presentation makes it clear that NetBuild is little more than > an IMakefile system that is grid-aware. Some of the goals of this project > (e.g., "automate the process of selecting ... software libraries over the > Internet", "automate the construction of such libraries") are quite lofty. > But the superficial manner in which these topics are "solved" (by NetBuild) > indicate that the researchers have a very incomplete understanding of the > issues involved. For instance, selection of appropriate software is not > merely a matter of tagging libraries with architectural parameters and > selecting them. John Rice and colleagues at Purdue have been trying to > design such automatic algorithm selection systems for the past 20 years, and > the problem is one of the most open issues in numerical computing. Please > see the work by this group for more holistic approaches to this problem. we have added text to the goals section to clarify that our goals are more modest than automatic algorithm selection and other problems which this reviewer recommends that we address. nevertheless, we believe that NetBuild will be very useful even without solving that problem.