Changes between Version 24 and Version 25 of GuiRpcProtocol

Timestamp:

Oct 4, 2009, 10:06:47 PM (15 years ago)

Author:

Nicolas

Comment:

m

GuiRpcProtocol

@@ -36 +36 @@
 </boinc_gui_rpc_reply>
 }}}
-although individual commands may specify a different reply. For example, any command where the client is requesting information from the server would get that extra information in the command reply, instead of {{{<success/>}}}.
+although individual commands, especially those that retrieve data, may return the requested information ''instead of'' {{{<success/>}}}.
 
 If a command isn't successful, the reply is:
@@ -45 +45 @@
 </boinc_gui_rpc_reply>
 }}}
-Clients should not try to parse the error message. The current gui_rpc_client.C library sometimes tries to parse errors, but this is very unreliable, since the message wording can change (and has changed) between RPC server versions. (r15942 even changed "unrecognized op")
+Clients should not try to parse the error message. The current gui_rpc_client.cpp library sometimes tries to parse errors, but this is very unreliable, since the message wording can change (and has changed) between RPC server versions. (r15942 even changed "unrecognized op")
 
 == Authentication == #auth
@@ -83 +83 @@
 There are some XML elements (like {{{<project>}}}, {{{<result>}}}, {{{<workunit>}}}, and {{{<app>}}}) that are common to many command replies. Such elements ~~are~~ will be documented in this section.
 
-The XML responses are relatively flat, and are parsed in one pass. The relationship between XML elements is determined by what was parsed before it, instead of based on the tree hierarchy like other XML formats do. For example, {{{<result>}}} elements that come ''after'' a particular {{{<project>}}} element are results that belong to that project; instead of those results being ''inside'' the {{{<project>}}} element.
+The XML responses are relatively flat, and are parsed in one pass. The relationship between XML elements is determined by what was parsed before it, instead of based on the tree hierarchy like other XML formats do. For example, {{{<result>}}} elements that come ''after'' a particular {{{<project>}}} element are results that belong to that project. They won't be ''inside'' the {{{<project>}}} element.