izuzak / pmrpc Goto Github PK

Since API for inter-window communications is fairly similar to the one of WebSocket and DataChannels (send() instead of postMessage(), and both answering on 'message' events) it would be a simple and nice feature to expand pmrpc functionality to add it.

The use case I'm thinking about is to be able to use without any diference a functionality running localy on a WebWorker or on a remote server using WebSockets, or extending the inter-window functionality to diferent browsers running on diferent machines thanks to DataChannels.

The hello-world example is throwing the following exception:
Uncaught Error: SyntaxError: DOM Exception 12 pmrpc.js:425
Browser: Google Chrome Version 26.0.1410.64 m
Windows 7 Home Premium, Service Pack 1, 64-bit

In IE 10, the following error is thrown:
SCRIPT5022: SyntaxError
pmrpc.js, line 425 character 7

This occurs when the example is read from the local file system/disk (rather than a webserver).

I'm using your library inside a window that is getting external postmessages. Those messages are in an object format, so 'indexOf' isn't defined. Can you add protection to make sure serviceCallEvent.data is a string before calling indexOf?

I have a parent window that dynamically adds an iframe to its body. I'm (intermittently) getting a "Application error. Destination unavailable" when calling a method in the parent window from the iframe.

Here is the code in the parent window:

    pmrpc.register( {
      publicProcedureName: "getProjectInfo",
      procedure: function() {
        console.log( 'received Rpc call getProjectInfo' );
        return "here's the info";
      }
    });

and here is the code in the iframe:

pmrpc.call({
  destination: parent,
  publicProcedureName : "getProjectInfo",
  retries: 40,
  timeout: 40000,
  onSuccess : function(returnObj) { 
    var projectInfo = returnObj.returnValue; 
    console.log("success returned from pmrpc.getProjectInfo with value " + JSON.stringify( projectInfo ) ); 
  },
  onError : function(statusObj) {
    console.log("error received after calling pmrpc.getProjectInfo: " + statusObj.message );
  }
});

As you can see, I get this problem even with very high timeout and retries. I noticed in one of your closed issues that someone had tried changing -1 to -2 in this part of the pmrpc code:

} else if (callObj.retries <= -2) {
  processJSONRpcResponse(...

And that does indeed "fix" the problem, but I'm wondering if there is a better fix, ie, one that would not turn off timeouts.

Thanks!
John

Any way you could make a tagged version?

RPC calls initiated from a sandboxed iframe fail with message:

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.

Reason is that sandboxed iframe has null origin thus "*" shall be used instead null.

Hey, can you expand the hello example to include an rpc from worker to a function registered in the parent?

Your API doc says:

pmrpc.discover({
nameRegex : ".goodName.",
callback : function(discoveredMethods) {
pmrpc.call({
destination : discoveredMethods[0].destination,
publicProcedureName : discoveredMethods[0].publicProcedureName,
params : ["Hello World!"],
destinationDomain : "*",
};
}
});

This is missing a parenthesis:

pmrpc.discover({
nameRegex : ".goodName.",
callback : function(discoveredMethods) {
pmrpc.call({
destination : discoveredMethods[0].destination,
publicProcedureName : discoveredMethods[0].publicProcedureName,
params : ["Hello World!"],
destinationDomain : "*",
}); <-------- added )
}
});

Also, in the pmrpc code, nameRegex seems to default to .* if publicProcedureName is not defined on the params object in pmrpc.discover(params object) WHEREAS the API doc snippet above suggests that it can actually be set by the user to any RegEx ...

The Problem:

I'm attempting to use asynchronous callbacks with a pmrpc call. It would seem that the call is timing out with not enough retries to get my onSuccess callback to be called.

So, to test this hypothesis, in my project I, exaggerated the delay by using a setTimeout which seemed to cause the same problem consistently. I've replicated this scenario accurately in the demo below.

I attempted to increase the number of retries first instead of the timeout because I don't want to increase the delay of the callback if I can help it - calling-back sooner is better than later; however, increasing the retries from it's default value doesn't seem to yield any different result.

Finally, I increased the timeout to something larger than the delay and my onSucces got called but onError was also being called 3 times after (with two different messages).

Questions

1. By watching the onError function I observe only 4 onError calls (when the default is 5 retries). Why? Is there something else going on here?
2. If the default timeout is 1000ms and the delay before callback is 3000ms then why does the onSuccess not get fired on the 4th or 5th retry?
3. If I set the timeout to 3500ms (when the delay is still 3000ms), onError is still being called. Why? Again, is there something else going on here?
4. For every "set" of onError calls there is always 1 with message Method not found. The requestd remote procedure does not exist or is not available. and 2 or 3 with message Application error. Destination unavailable. What's up with that? (Also, not to be a dick, but there's a typo "... The requestd remote...")

Steps to Replicate / Using the Demo:

The demo's JS has a map object containing 2 key/value pairs. The HTML has 2 buttons. The pmrpc procedure/call pair are set up so that clicking a button in the "child" (iframe) will call the "parent" pmrpc procedure and callback with the respective map value.

1. Use the default timeout and retries. This will generate my initial results, 4 onError calls and no onSuccess calls.
2. Set the retries to 15. This results will be the same.
3. Set the timeout to 3500. This will allow the callback to call and will also call onError 3 times.

Demo:

jsfiddle: "Parent" document example
gist "Child" document (iframe source)

Note: I'm currently hosting the iframe document (I didn't know where else to put it for working jsfiddle example)

In #14 you mention the library could use some love, or even a rewrite. It would be helpful to have some if the problems enumerated somewhere so that potential contributors know what to look into.

Hi,

thanks for the quick response - with that extra hint I was able to make this

http://strelz12.cs.usm.edu/~strelz/physics-pmrpc/

previous version used a lot of hand-coded json/string/message/eval junk -- much cleaner with pmrpc.js

I'd be happy to contribute this example - a bit sexier than "hello worker" :)

strelz

Just testing something

I'm trying to run this code

// in iframe
pmrpc.call({
  destination: window.parent,
  publicProcedureName: 'test',
  onSuccess: .....
  ....
});

but i keep getting this error:

Unsafe JavaScript attempt to access frame with URL <some host> from frame with URL <some other host>. Domains, protocols and ports must match.

Is there any way to call a procedure defined in a parent window from an iframe using pmrpc?
Thanks,
Alex T

I've had regular instances of pmrpc hanging during a call. It appears it may be due to a division by zero leading to Infinity being passed to setTimeout.

The patch below appears to fix the issue:

From ce56cf15bbc48476d1edd598eb0c35f2a9c02c7a Mon Sep 17 00:00:00 2001
From: Jonathan Giddy 
Date: Fri, 1 Mar 2013 07:00:24 +0000
Subject: [PATCH] Fix division by zero, which leads to infinite timeout

---
 pmrpc.js |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/pmrpc.js b/pmrpc.js
index 27f9435..8d5be18 100644
--- a/pmrpc.js
+++ b/pmrpc.js
@@ -454,8 +454,9 @@ pmrpc = self.pmrpc =  function() {
       }
     } else {
       // if we can ping some more - send a new ping request
+      var retries = callObj.retries
       callObj.status = "pinging";
-      callObj.retries = callObj.retries - 1;
+      callObj.retries = retries - 1;
 
       call({
         "destination" : callObj.destination,
@@ -475,7 +476,7 @@ pmrpc = self.pmrpc =  function() {
         if (callQueue[callId] && callQueue[callId].status === "pinging") {
           waitAndSendRequest(callId);
         }
-      }, callObj.timeout / callObj.retries);
+      }, callObj.timeout / retries);
     }
   }
 
-- 
1.7.5.4

Test page: http://ivanzuzak.info/pmrpc/test/testingContainer.html

Contains references to:
http://code.jquery.com/qunit/git/qunit.css
http://code.jquery.com/qunit/git/qunit.js

Which at the time of writing are returning 404.

Solution - use:
http://code.jquery.com/qunit/qunit-1.12.0.css
http://code.jquery.com/qunit/qunit-1.12.0.js