Hi Derrell,
thank you for you immense contribution.
I am not that inside RPC, so I have no comments to this part of your
work. Just a few other comments.
#1:
---------
Are you sure you want to change this:
+ var vText = this.getIframeTextContent();
+
switch(this.getResponseType())
{
case qx.constant.Mime.TEXT:
- return this.getIframeTextContent();
+ return vText;
break;
case qx.constant.Mime.HTML:
- return this.getIframeHtmlContent();
+ return vText;
break;
What's the reason to return the text for mimeType HTML?
#2:
---------
+ * Derrell Lipman
What's about to also add a contact email addresse to the source files,
like the other authors handle this?
#3:
---------
Could you rename both JSON and RPC javascript files and class names to
CamelCase Style. Results in JSON => Json, RPC => Rpc. we have also made
this decision in other areas and I think it was a good choice.
#4:
---------
Why:
var handleRequestFinished = function() {
and not just:
function handleRequestFinished()
should be also local and not global in this case.
Regards,
Sebastian
[EMAIL PROTECTED] schrieb:
> Hi all,
>
> Attached is a patch which I'd like opinions on. I've spent quite a bit of
> time trying to both make the Transport/RPC mechanism reliable and robust, and
> to make it easy to use for a variety of applications.
>
> Changes:
>
> - As I tested, I discovered many possible error/failure conditions that were
> caught by javascript error rather than handled by providing an error to the
> user. Hopefully, I've trapped all possibilities now, so exceptions should
> be triggered in all cases of non-programmer-generated errors (e.g. network
> failures, web server being shut down, etc.).
>
> - If multiple asynchronous requests are issued simultaneously, there is now a
> mechanism to be able to associate a received response or error with its
> associated request. Each request is given a unique "sequence number". If
> the application cares to be able to do this association, it can retrieve
> the sequence number by calling the getSequenceNumber() method after issuing
> the asynchronous call. When the handler is called, the sequence number or
> "id" is passed along with the result and/or exception.
>
> - The JSON-RPC implementation has been modified to more closely follow the
> JSON-RPC specification. The fields in a remote request are now "service",
> "method", "id" and "params". The fields in a response are (for success)
> "id" and "result", or for failure, "id" and "error".
>
> - Since the JSON-RPC spec is lacking in details about an Error object, this
> implementation defines two fields in an Error object: "code" and
> "message". The "code" is an integer with the following currently-defined
> values:
>
> 1 - Illegal Service
> The service name contains illegal characters or is otherwise deemed
> unacceptable to the JSON-RPC server.
>
> 2 - Service Not Found
> The requested service does not exist at the JSON-RPC server
>
> 3 - Class Not Found
> If the JSON-RPC server divides service methods into subsets (classes),
> this indicates that the specified class was not found. This is
> slightly more detailed than "Method Not Found", but that error would
> always also be legal (and true) whenever this one is returned.
>
> 4 - Method Not Found
> The method specified in the request is not found in the requested
> service.
>
> 5 - Parameter Mismatch
> If a method discovers that the parameters (arguments) provided to it
> do not match the requisite types for the method's parameters, it
> should return this error code to indicate so to the caller.
>
> 6 - Permission Denied
> A JSON-RPC service provider can require authentication, and that
> authentication can be implemented such the method takes authentication
> parameters, or such that a method or class of methods requires prior
> authentication. If the caller has not properly authenticated to use
> the requested method, this error code is returned.
>
> 7 - 999
> All error codes up to 999 are reserved for future revisions.
>
> 1000 - X
> Error codes including and above 1000 are for service method to return
> application-specific error code information. These codes will never
> be generated by the "generic" portion of a JSON-RPC server, but rather
> by the specific service methods. The meaning of them is only
> meaningful between the method and the caller.
>
> The "message" field provides additional explanation that the JSON-RPC
> server deems useful to the caller.
>
> - There is no defined way to pass a javascript Date object in JSON. Previous
> to these revisions, a modification had been made to the JSON code to pass a
> Date object by encoding "new Date(ms_since_epoch)" in the JSON request.
> Unfortunately, that encoding has three problems:
>
> 1. It requires that the JSON server/peer be implemented in a language that
> provides a Date object.
>
> 2. It requires that the JSON server/peer be implemented in a language that
> has a "new" operator.
>
> 3. It passes an integer value, milliseconds since the beginning of the
> epoch, that does not (in many cases) fit in a 32-bit signed integer.
> If the JSON server/peer is implemented in a language that does not
> support large integers, that value can not be represented as an
> integer. Although the value can be represented as a floating point
> number, precision is lost.
>
> To solve these problems, this revision passes a javascript Date object as
> an object with two data fields:
>
> secSinceEpoch -
> The number of seconds since the beginning of the epoch, defined as
> midnight on 1 Jan 1970
>
> msAdditional -
> The additional number of milliseconds (in the range [0 - 999])
>
> In order to allow the JSON server to know that this is actually a Date
> object, we use the JSON-RPC-defined class hint mechanism with the hint
> field, __jsonclass__, set to "Date".
>
> A JSON object representing a Date is therefore generated like this:
>
> // assume 'd' was obtained from something like: d = new Date();
> jsonObj = new Object();
> jsonObj.__jsonclass__ = "Date";
> jsonObj.secSinceEpoch = Math.floor(d.getTime() / 1000);
> jsonObj.msAdditional = d.getTime() % 1000;
>
> (This is currently the only implemented use of class hints in this code,
> but the function parsing them is written to be extensible if we ever
> discover new needs for it.)
>
> - There are four test programs in demo/test :
>
> RPC_1.html -
> By default, calls an "echo" service on the same server as qooxdoo was
> requested from, using the services URL of "/services/". Either a
> synchronous or asynchronous request may be issued. Additionally, a
> "cross-domain" checkbox allows specifying whether to use XmlHTTPTransport
> or IframeTransport. The service and URL may be specified to be other
> than "echo" and "/sevices/".
>
> RPC_2.html -
> This tests multiple concurrent asynchronous calls to the server by
> calling the "sleep" method, passing decreasing amounts of time to sleep.
> This test shows use of the id/sequence number to associate a result with
> its initiating request. It also shows (unfortunatly) the strictness with
> which the browser writers implemented HTTP. Only two outstanding HTTP
> requests may be active at one time; additional requests are queued
> internally by the browser. By default this test requests sleep for 10
> and 5 seconds. A checkbox allows issuing more requests than the
> underlying HTTP will allow concurrently, in which case requests to sleep
> for 30, 25, 20, 15, 10, and 5 seconds are issued. By examining the
> resulting return times, you'll clearly see the maximum of 2 concurrent
> requests. Even two, though is better than only 1 for some priority /
> out-of-band data needs.
>
> RPC_3.html -
> A test of each of the primitives of JSON-RPC requests, using synchronous
> requests. DANGER, WILL ROBINSON!!! Using synchronous requests is
> dangerous. In Firefox (and I'm not sure about IE), the entire browser
> hangs during a synchronous request, so if the server does not respond
> immediately, nothing else in the browser will operate, including even
> window refreshes. This "feature" can be tested using RPC_1.html and
> requesting either the "sink" or "sleep" method.
>
> RPC_4.html
> This issues each of the same primitives as in RPC_3.html, but using the
> asynchronous interface.
>
> - The RPC_*.html tests are currently implemented to talk with a new PHP-based
> JSON-RPC server, located in backend/php. To use this JSON-RPC server,
> place the 'services' directory in the root of your web server
> (e.g. /var/www) and ensure that PHP (preferably 5 but 4 should work too) is
> installed. The file index.php is a "generic" JSON-RPC server; it receives
> the requests and validates that they are properly formed. If they are, it
> loads the PHP class file and calls the requested method. All of the test
> methods are in the class file called services/qooxdoo/test.php,
> corresponding to the service "qooxdoo.test". (The primitives test cases
> were derived from the tests in free-ria. Thanks.)
>
> - I made a number of edits to the Java-based JSON-RPC server, but they are
> incomplete. I don't have a Java environment to work with, nor have I ever
> done any Java work. A competent Java programmer should be able to make the
> requisite changes in about 15 minutes. Specifically,
>
> - I made the changes to more closely follow the JSON-RPC spec. I may have
> missed a few, though.
>
> - I made comments of where to return an appropriate error code instead of
> the error "name", but that needs to be completed
>
> - The Date changes need to be made. These "should" be as simple as the
> function in javascript that reverse the procedure. See
> qx.io.JSON.parse() and qx.io.JSON._fixObj() in qx/io/JSON.js. The Java
> procedure should be quite similar.
>
> Patch attached. Comments, please!
>
> Cheers,
>
> Derrell
>
>
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
