Changes between Version 18 and Version 19 of RemoteJob

Timestamp:

Feb 3, 2011, 11:10:48 AM (13 years ago)

Author:

tonig

Comment:

minor esth.

RemoteJob

@@ -193 +193 @@
 
 In BOINC you can't have 2 WU with different input but
-with the same name (say, "environment.dat"), 
-because it will already be in the folder "download" on your
+with the same name (say, ''environment.dat''), 
+because it will already be in the folder ''download'' on your
 project. So you would have to rename the file or set manually the file
 property (URL...) in WU.  Is it the same with RBoinc? Will the file be
@@ -200 +200 @@
 
     No, it will be handled correctly: file names are made
-    unique (in fact, equal to the file's md5), even though the
+    unique (in fact, equal to the file's MD5), even though the
     submitter used the same name for different contents. (It's fairly
     common e.g. for 1000 WUs to have in common at least one of the
@@ -218 +218 @@
 
 Will there be a problem if a user send simultaneously 1000 jobs by a
-script (as I saw you used temp folders which were deleted at the end
-of 1 submission) ?
-
-    It's perfectly fine (quite common indeed).
+script?
+
+    It's perfectly fine (and  indeed common).
 
 === Retrieve ===
@@ -249 +248 @@
     This important point should be clarified:
 
-      1. a client ("volunteer") computes a WU 
-      2. results are stored in 
+      1. a client ("volunteer") computes and returns a WU, which is validated as usual
+      1. results are stored in 
       "workflow_results/GROUPNAME" (something like
-      name-USER_GROUPNAME-2-10-RND1234-...)  
-      3. the WU is assimilated:
-      assimilator executes the '''process''' script in the
-      workflow_results/GROUPNAME 
-      4. '''process''' creates a WU
+      ''name-USER_GROUPNAME-2-10-RND1234-...'')  
+      1. the WU is assimilated: the 
+      assimilator should execute the {{{process}}} script in the
+      ''workflow_results/GROUPNAME''
+      1. {{{process}}} creates a WU
       corresponding the next step of the chain (if necessary)
-      5. repeat from 1
-
-    The "retrieve" operation is completely independent of the above
-    process: a "retrieve" can be requested at any time, and it will
-    download any results stored in workflow_results/GROUPNAME.
+      1. repeat from 1
+
+    The ''retrieve'' operation is completely independent of the above
+    process: a retrieve can be requested at any time, and it will
+    download any results stored in ''workflow_results/GROUPNAME''.
 
 
@@ -271 +270 @@
     Yes, scientists may request the outputs of successfully-completed WUs
     at any time (even if they are part of a still-ongoing chain of
-    WUs). Automatic retrieval on the issuing scientist's machine via
-    cron jobs is convenient.
+    WUs). ''Automatic'' retrieval on the issuing scientist's machine is conveniently 
+    done via cron jobs.
 
 
@@ -279 +278 @@
 === Portability and server coexistence ===
 
-Do you have an idea if your application is directly compatible with
-windows ?
+Is your application directly compatible with
+Windows?
 
     The '''client''' scripts are likely portable with minor changes
-    (just install a good perl interpreter and the required modules).
-
-
-Is it possible to use your commands with different BOINC projects ?
+    (just install a good Perl interpreter and the required modules).
+
+
+Is it possible to use your commands with different BOINC projects?
 
     Normally a ''RBoinc server'' is tied to the corresponding