Changes between Version 1 and Version 2 of Master Slave Protocol Http

Timestamp:

Jul 23, 2007, 10:43:54 PM (17 years ago)

Author:

cmlenz

Comment:

Minor corrections

Master Slave Protocol Http

@@ -4 +4 @@
 This is a proposal for an HTTP-based protocol enabling communication between the build master and various build slaves. The protocol presented here is not final yet, nor is it implemented. Just throwing ideas out there, basically.
 
-== Comparison the Previous BEEP Protocol ==
+== Comparison to the Previous BEEP Protocol ==
 
 The BEEP-based protocol currently used by Bitten is described on MasterSlaveProtocol.
@@ -17 +17 @@
 == Build Creation ==
 
-A new client connects to the build master and asks the master whether there are any pending builds it could perform. The slave does this by `POST`ing its profile to the master, which contains information such as:
- * The platform/architecture of the slave machine,
+A new slave connects to the build master and “asks” the master whether there are any pending builds it could perform. The slave does this by `POST`ing its profile to the master, which contains information such as:
+ * the platform/architecture of the slave machine,
  * the operating system,
  * the product name and version number of each of the dependencies of the project to build (for example, the C compiler or the Python runtime), and
@@ -27 +27 @@
 POST /build/ HTTP/1.1
 Host: example.org
-Content-Type: application/xml; charset=utf-8
+Content-Type: application/x-bitten+xml
 Content-Length: 666
 
@@ -45 +45 @@
 }}}
 
-The response contains the URL to a build recipe as the value of the `Location` header. At this point, the master has allocated a pending build entity in its database that can also be viewed as HTML at the specified URL using any HTTP user agent.
+The response contains the URL to a build recipe as the value of the `Location` header. At this point, the master has allocated a pending build entity in its database. The progress on this build can be viewed as HTML at the specified URL using any HTTP user agent.
 
 On the other hand, if the master has no work for the slave, it would return a `204 No Content` response:
@@ -95 +95 @@
   ''Open issue: details of the checkout process should also be reported back the master''
 
-After every completed step, the slave should make a `PUT` requests the `steps` member of build collection:
+After every completed step, the slave should make a `PUT` request to the `steps` member of build collection:
 
 {{{
@@ -109 +109 @@
 The `started` attribute specifies the date and time at which processing of this step was started. The `duration` attribute contains the number of seconds that it took to complete the step (this may include fractions).
 
-The `<result>` element may contain one or more child elements:
+The `<result>` element may contain one or more of the following child elements:
  * `<error></error>` elements indicate errors in the execution of the step,
  * `<log></log>` elements contain the build log output, and
@@ -120 +120 @@
 == Uploading of Build Artifacts ==
 
-If the recipe contains an `<upload>` element at the end of the recipe, the slave is expected to perform file uploads of any of the files specified. This is done using `PUT` requests the the `files` member of the build collection:
+If the recipe contains an `<upload>` element at the end (after all `<step>` elements), the slave is expected to perform file uploads of any of the files specified. This is done using `PUT` requests the the `files` member of the build collection:
 
 {{{