Can a provider also be a consumer

[adam c]

Hi,

I am using easyXDM to help me facilitate XDM between 3 domains:


Domain A <-> Domain B <-> Domain C

Domain C does not need to communicate with A.

Domain A has successfully opened a channel to Domain B.

When I create a new Rpc object in Domain B (in order to open a comms
channel with Domain C), it gives me an error:

undefined is not a function

This occurs at the following code:

send = getParentObject().Fn.get(config.channel, true)
(function(msg){
pub.up.incoming(msg, targetOrigin);
});

defined in SameOriginTransport - line 1299 of easyXDM.js (I am testing
so all three domains are currently the same).

It seems that this new Rpc is acting as a provider, even though I've
specified a "remote" because I intend it to behave as a consumer. Is
there anyway for one Rpc object on Domain B to act as provider and
another Rpc object on Domain C to act as consumer?

Thanks!

Adam

[Adam Creeger]

Sorry, that last sentence should read:

Is there anyway for one Rpc object on Domain B to act as provider and

another Rpc object in the same page on Domain B to act as consumer?

[adam c]

Ok, in typical fashion, I answered this myself seconds later by using

{
isHost: true,
remote: xxxxxx
}

in the config for the second Rpc object.

Thanks for thinking of this scenario!

Adam

On Oct 17, 6:07 pm, Adam Creeger <adamcree...@gmail.com> wrote:
> Sorry, that last sentence should read:
>
> Is there anyway for one Rpc object on Domain B to act as provider and
> another Rpc object in the same page on Domain B to act as consumer?
>

[Øyvind Sean Kinsey]

This is not a supported use case due to an inherent risk of collisions (depending on which underlying transport stack is used).

If you want something close to this, then simply write into an inline iframe that you use to sandbox the 'consumer' - this way no such collisions will occur. 


Øyvind Sean Kinsey
oyv...@kinsey.no
http://kinsey.no/blog/index.php/about/

[adam c]

Ok - I guess my celebration was premature.

So, to clarify what you mean:

In the page on Domain B:

1. Programmatically create an iframe, lets call this "iframe_A".
2. Programmatically write a div into that iframe, we'll call this
"div_A"

Still in the parent page on Domain B,

3. Create a new Rpc object, using div_A as the container.

Is this correct?

Or do you suggest creating the Rpc page using javascript written
inside iframe_A.

Thanks again!

Adam

On Oct 18, 1:09 am, Øyvind Sean Kinsey <oyv...@kinsey.no> wrote:
> This is not a supported use case due to an inherent risk of collisions
> (depending on which underlying transport stack is used).
>
> If you want something close to this, then simply write into an inline iframe
> that you use to sandbox the 'consumer' - this way no such collisions will
> occur.
>
> Øyvind Sean Kinsey

> oyv...@kinsey.nohttp://kinsey.no/blog/index.php/about/

>
>
>
>
>
>
>
> On Tue, Oct 18, 2011 at 3:07 AM, Adam Creeger <adamcree...@gmail.com> wrote:
> > Sorry, that last sentence should read:
>
> > Is there anyway for one Rpc object on Domain B to act as provider and
> > another Rpc object in the same page on Domain B to act as consumer?
>

[Øyvind Sean Kinsey]

var iframe = document.body.appendChild(document.createElement("iframe"));

iframe.contentWindow.document.write(...

iframe.contentWindow.document.close();

Load the easyXDM code for the consumer inside this iframe (you can easily write `easyXDM = parent.easyXDM; foo = new easyXDM...`) - now this will give you a 'sandbox' without incurring any extra requests etc., and you can freely communicate between them using parent/iframe.contentWindow.

[Adam Creeger]

Great. Thanks.

2011/10/18 Øyvind Sean Kinsey <oyv...@kinsey.no>

[Adam Creeger]

Hello. Again. :-)

I've implemented this... My implementation looks like this gist:

https://gist.github.com/a863be244fe9112828a1

This "appears" to be working, but so did the old way (in my simple dev environment)...

When I looked at the DOM, I was surprised to see both the inline iframe, and the Rpc iframe created as siblings - both children of the page on Domain B. Is this what you expected? For example:

https://gist.github.com/06bf8dcde468b84b1276

I would have expected the Rpc iframe to be a child of the inline iframe...

Thanks as always,

Adam

2011/10/18 Øyvind Sean Kinsey <oyv...@kinsey.no>

var iframe = document.body.appendChild(document.createElement("iframe"));

[Øyvind Sean Kinsey]

Ah, easyXDM 'captures' the 'document' propert in a closure', so 'easyXDM = parent...' wont work. Load it normally (from cache) and you should be good to go.

[Adam Creeger]

Hi Sean,

I'm sorry to resurrect such an old thread, but we are having issues with IE in this situation... I'm wondering if we're missing something obvious.

Our current implementation looks like this gist: https://gist.github.com/74edf7224572918abbf3

The problem is that easyXDMArgs is not defined in the child (sandbox) iframe. Could this be due to a document.domain issues? I never set document.domain explicitly anywhere. If so, do you have any advice for solving the timing issues that exist with setting document.domain? 

Thanks so much for your continued help,

[Øyvind Sean Kinsey]

I'm going to guess that IE simply resets the scope when opening the document using document.write...
Why not simply serialize the args as JSON and include this in the source of the new document?

[Øyvind Sean Kinsey]

Right, saw your comment now..

Then I would simply define a function in the sandbox, wrapping this code, and taking the args as an argument.

Write the doc and call the method...

Øyvind Sean Kinsey
oyv...@kinsey.no
http://kinsey.no/blog/index.php/about/

2011/12/15 Øyvind Sean Kinsey <oyv...@kinsey.no>

[Adam Creeger]

Ok, I'll see if I can get that to work. Given that the issue is might document.write, I'll look into work arounds for that too.

Out of interest, what Transports suffer collisions if a consumer is also a provider? I'm guessing the HashTransport - but anything else?

Thanks,

Adam

[Adam Creeger]

By the way, I solved this issue across all browsers by changing my approach. Instead of pushing the easyXDM args to the contentWindow, I had the contentWindow pull them from the parent.

An example of this can be found at:

https://gist.github.com/1ea83380571bb4c588d7