Subject: CCPE Portal C558 From: Matthias Mueller Date: Wed, 19 Sep 2001 14:25:50 +0200 (CEST) To: fox@csit.fsu.edu X-UIDL: 3f69546a94150000 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Received: by mailer.csit.fsu.edu (mbox gcfpc) (with Cubic Circle's cucipop (v1.31 1998/05/13) Sun Oct 14 17:39:10 2001) X-From_: fox@mailer.csit.fsu.edu Sun Oct 14 17:37:46 2001 Return-Path: Delivered-To: gcfpc@csit.fsu.edu Received: from dirac.csit.fsu.edu (dirac.csit.fsu.edu [144.174.128.44]) by mailer.csit.fsu.edu (Postfix) with ESMTP id 7E02B23A07 for ; Sun, 14 Oct 2001 17:37:45 -0400 (EDT) Received: from localhost by dirac.csit.fsu.edu (AIX4.2/UCB 8.7) id RAA92796; Sun, 14 Oct 2001 17:37:44 -0400 (EDT) Resent-Message-Id: <200110142137.RAA92796@dirac.csit.fsu.edu> Replied: Fri, 28 Sep 2001 21:37:16 -0400 Replied: Matthias Mueller Delivered-To: fox@csit.fsu.edu Received: from artemis.rus.uni-stuttgart.de (artemis.rus.uni-stuttgart.de [129.69.1.28]) by mailer.csit.fsu.edu (Postfix) with ESMTP id 1F85B23A14 for ; Wed, 19 Sep 2001 08:25:53 -0400 (EDT) Received: from pcgpc6.rus.uni-stuttgart.de (pcgpc6.rus.uni-stuttgart.de [129.69.14.61]) by artemis.rus.uni-stuttgart.de with ESMTP id OAA16649 for ; Wed, 19 Sep 2001 14:25:52 +0200 (MET DST) env-from (rusmatt@pcgpc6.rus.uni-stuttgart.de) Received: (from rusmatt@localhost) by pcgpc6.rus.uni-stuttgart.de (8.9.3/8.8.8) id OAA14643; Wed, 19 Sep 2001 14:25:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15272.36558.750508.462928@pcgpc6.rus.uni-stuttgart.de> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Sender: rusmatt@pcgpc6.rus.uni-stuttgart.de Resent-To: Geoffrey Fox Resent-Date: Sun, 14 Oct 2001 17:37:44 -0400 Resent-From: Geoffrey Fox C: Paper and Referee Metadata Paper Number Cnnn: C558 Date: 19 Sep. 2001 Paper Title: The Perl Commodity Grid Toolkit Author(s): Stephen Mock, Mary Thomas, Gregor von Lazewski Referee: Matthias Mueller, Edgar Gabriel, Michael Resch Address: HLRS Allmandring 30 70550 Stuttgart Germany Referee Recommendations. Please indicate overall recommendations here, and details in following sections. accepted provided changes suggested are made D: Referee Comments (For Editor Only) ------------------------------------ E: Referee Comments (For Author and Editor) ------------------------------ This paper is a very interesting short sketch of a developing project. It describes quite well the modules and interactions with other tools. What is missing is reference to related work which would help to see what is so specific about the project. Furthermore the concepts and ideas behind the modules and tools have to be added. The authors mention their object oriented approach at several places, but they don't elaborate it further. If this short sketch is worked out into a full paper it may be very interesting. F: Presentation Changes The paper is not formatted according to the guidelines of CPE special issue, an abstract is essential. The authors should read the instructions at http://www.interscience.wiley.com/jpages/1040-3108/ and get the appropriate style files. More information about the similarities and differences between the Perl CoG and the other CoGs should be provided. Do they have the same design and architecture? What are the reasons for possible differences? What is special for Perl? Figure 1 shows the architecture of a portal developed with a different toolkit (GridPort). The authors state that the architecture would be the same if the Perl CoG had been used. Nevertheless the relevance of this figure for a paper about the Perl CoG is unclear. Would the architecture differ if a non Perl toolkit had been used for the implementation? Since the Globus client utilities are required for the Perl CoG the statement "the requirements for the Perl CoG are minimal, and the installation is simple" is a contradiction to the earlier statement "the installation of the Globus client utilities may present some challenges". The whole section 3 resembles more an installation instruction than a scientific paper. We recommend to remove this section and to include the relevant information provided here in the description of the architecture. In section 4 the handling of interactive and batch jobs are described. In the presented context is is not clear what the differences between these two kind of jobs are and why only the batch jobs have been wrapped in a object oriented module. The authors should describe what distinguishes the RSL module from a string class library. What abstraction level is provided to the user? Is it the responsibility of the user to get a correct RSL string or is this guaranteed by the RSL module in an OO style fashion? Only the search and RSl modules are pure Perl implementations, all others are simple wrappers to the underlying Globus utilities. Since the potential benefit of a pure Perl implementation is huge and also mentioned by the authors it would be very interesting why this approach was taken by the Perl CoG developers. Was it a matter of convenience for the developers or are there more fundamental issues involved? .