JSON-RPC Calls Across User Contexts?

[A. Shore]

Guys, be gentle with this noob! (I've been looking a long time for
something like this, and a too-quick look tells me that JSON-RPC might
work for me in this.)

I have a conventional web/php/js application in which there's an
occasional server-side need - within user X's context - to invoke a
remote JS function in Y's and Z's pages, sans a page refresh there.
These are all served by the same server. I control the procedure name
and parameters.

The common implementation of such a requirement is often a timed
client poll of the server, accepting the latency and bandwidth waste
in doing so. I'd prefer not to do so.

I'm also trying to avoid the use of a daemon as in chat operations,
since there's no clear-to-me need for this, given that each user's
interaction here is initiated server-side - but in the wrong guy's
context.

Opinions solicited: Will JSON-RPC work in the above? If not, what's
missing?

[Matt (MPCM)]

On Saturday, January 5, 2013 9:17:18 AM UTC-5, A. Shore wrote:

Guys, be gentle with this noob!  (I've been looking a long time for
something like this, and a too-quick look tells me that JSON-RPC might
work for me in this.)

JSON-RPC is a good fit for this, in terms of the messaging formats. You can use it for for X,Y, and Z to communicate with your server. With your server acting as a message exchange hub.

I have a conventional web/php/js application in which there's an 
occasional server-side need - within user X's context - to invoke a
remote JS function in Y's and Z's pages, sans a page refresh there.
These are all served by the same server.  I control the procedure name
and parameters.

The common implementation of such a requirement is often a timed
client poll of the server, accepting the latency and bandwidth waste
in doing so.  I'd prefer not to do so.

I'm also trying to avoid the use of a daemon as in chat operations,
since there's no clear-to-me need for this, given that each user's
interaction here is initiated server-side - but in the wrong guy's
context.  

Opinions solicited:  Will JSON-RPC work in the above?  If not, what's
missing?

In terms of transports, long polling, daemons, etc... those are a separate, but related topics. JSON-RPC isn't going to immediately 'solve' any of those issues. Specific implementations might, but again your talking about a couple concepts at one, and multiple client/server relations for this to work.

In particular, if you are expecting the results of foo(bar) being executed on Y and Z, initiated by X... are you expecting the results to be returned and sent back X?

At this point, it is starting to sound more like a pub/sub solutions to me.... in addition to, or in place of, JSON-RPC. 

Some of things you imply shouldn't be `need` (polling/daemons), might be. But the general answer is yes, your specific answer is going to be more complicated as you are having much more than a client/server relationship between 2 peers.

Code is data too, so this is really just about data exchange.

--
Matt (MPCM)

[Arnie Shore]

Cutting to the chase: " ... if you are expecting the results of

foo(bar) being executed on Y and Z, initiated by X... are you

expecting the results to be returned and sent back X? ... "

1. Yes, foo(bar) would be executed on Y and Z, initiated by X. (
Function foo(bar) would exist in the web pages currently displayed at
Y and Z. )

2. Nothing wd be returned other than a succeeds/fails value.

I'm gaining the impression that what I describe is a
security/permissions issue - access to the user's current browser page
- and less a data issue. If so, then it's probably impossible in an
http environment, given security protections built into current
browsers. It's the RPC factor that drew my attention.

AS

On 1/5/13, Matt (MPCM) <wicke...@gmail.com> wrote:
> On Saturday, January 5, 2013 9:17:18 AM UTC-5, A. Shore wrote:
>
>> Guys, be gentle with this noob! (I've been looking a long time for
>> something like this, and a too-quick look tells me that JSON-RPC might
>> work for me in this.)
>>
>
> JSON-RPC is a good fit for this, in terms of the messaging formats. You can
>
> use it for for X,Y, and Z to communicate with your server. With your server
>
> acting as a message exchange hub.
>

> I have a ...

[Matt (MPCM)]

On Sunday, January 6, 2013 10:26:06 AM UTC-5, A. Shore wrote:

Cutting to the chase: " ...  if you are expecting the results of
foo(bar) being executed on Y and Z, initiated by X... are you
expecting the results to be returned and sent back X? ... "

    1.  Yes, foo(bar) would be executed on Y and Z, initiated by X.  (
Function foo(bar) would exist in the web pages currently displayed at
Y and Z. )

    2.  Nothing wd be returned other than a succeeds/fails value.

I'm gaining the impression that what I describe is a
security/permissions issue - access to the user's current browser page
- and less a data issue.  If so, then it's probably impossible in an
http environment, given security protections built into current
browsers.  It's the RPC factor that drew my attention.

Security and permissions in the browser will not prevent this at all, it is just a matter of negotiating contexts. But you are correct that it can't be done as a simple client-server setup, since X cannot connect directly to Y.

What you need is for N to be a proxy (for single calls) or a proxy map/reducer (for many calls). How it gets done in practices is more complicated.

If you ignore the transport complications of browsers/HTTP for a moment.

N = server
X sends request (tell Y,Z to foo(bar)) to N
    N sends request to Y,Z calling foo(bar)
    Y,Z (in time) send response to N
N collects results and sends them as response to X's (Y said, Z said).

For me, I would prefer X,Y,Z to act as clients and then to have N to act as the server to all.

Anyway, since JSON-RPC just focuses on the roles, their rules, and the object shapes, you are free to use it and layer it with different transport approaches and layerings of client/server roles as needed.

Give it a try, and see how you like your options with either method.

--
Matt (MPCM)

[Shane Green]

Yeah, it's a general client-server limitation.  Only the client can initiate an interaction; there is no way for the server to reach out to a client, only ways for the clients to reach the server.  In HTTP an "interaction" is composed of an HTTP request, and the corresponding HTTP response.  The request is always sent by the client to the server, and the server returns the response to the client.  This may take place over an existing connection, or it may take place over a new connection, all of which is somewhat immaterial to the conversation as building blocks of HTTP are the single request/response transactions--as long as they are not broken apart, the conversation is complete.  A remote-procedure-call over HTTP is achieved by the client sending an HTTP POST request to the web-server which contains an RPC invocation in it.  An application on the server handles the invocation, and the response is packaged into an appropriate RPC response and returned as the HTTP response.  Because there is no way for the server to initiate a request to the client, there is no way for the server to invoke a method in the client's browser using RPC, unless the client periodic polls for pending commands and then executes these commands themselves.  That's how you can workaround this limitation, as it allows the client to initiate the request for pending commands; the client can then return the response to the server in a subsequent HTTP POST request.  JSON-RPC is an excellent RPC representing for those pending commands because each JSON-RPC message has a unique request ID, which is included in the corresponding JSON encoded response that the client will POST back.  This can then be used by an application on the server to correlate the incoming response with a pending command it had enqueued to have executed by the client's browser.  

Shane Green 

www.umbrellacode.com

805-452-9666 | sh...@umbrellacode.com

--
You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To post to this group, send email to json...@googlegroups.com.
To unsubscribe from this group, send email to json-rpc+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-rpc?hl=en.