ORB terminology

[Michael Clark]

Hi guys,

Just a thought on class naming that I've had in the back of my mind.

I was never really happy with the terminology when I created
CallableReference - it is a bit of a non-standard term.

Instead of having Reference and CallableReference I was thinking it may
be better to instead have Reference and CallableProxy (I believe the
latter is a known term) or even just plain Callable. When someone reads
the docs this would make more sense no?

The other note is on the ability to pass a CallableReference back to a
method on the server and have it act in much the same way as a Reference
- the JS client would need to detect them in toJSON ()typeof o[attr] ==
"function" && o.prototype == ...) and substitute it for the relevant
JSON. The serializer will already unmarshall them I believe. I believe
this was raised on the json-rpc-java list some time back.

Michael.

[William Becker]

That would be a good idea. I'm sick of accidentally writing CircularReference when i mean CallableReference and vice versa. Maybe both Ref and CallableRef should both have their names changed so they are still similar. I have always felt that a Callable Ref is just an extension of a Ref (as it can be used in the same places, but also provides functions).

[Michael Clark]

William Becker wrote:
> That would be a good idea. I'm sick of accidentally writing
> CircularReference when i mean CallableReference and vice versa. Maybe
> both Ref and CallableRef should both have their names changed so they
> are still similar. I have always felt that a Callable Ref is just an
> extension of a Ref (as it can be used in the same places, but also
> provides functions).

I had more meant removing the word Reference from CallableReference
although your right, CallableReference is a derivation of Reference. In
any case it is not that an important change. I just had been looking for
what others call the equivalent of a CallableReference (and in the
client it is in fact a Proxy).

This brings up another point about the JS client. There is actually a
design flaw that dates back to the original client code dervied from
Jsolait. The Client and the Proxy are in the same class
JSONRpcClientclass (it is a bit ugly to me how the proxies are added to
the fields of the client). My feeling is they should be separated at
some point eg. JSONRpcClient and JSONRpcCallable(Proxy).

Then instead we would be essentially resolving a CallableReference
(CallableProxy or whatever) from the client. e.g.

instead of:

var jsonrpc = new JSONRpcClient(...);
jsonrpc.someobject.doSomething();

we would have (which I think is much more natural):

var jsonrpc = new JsonRpcClient(...);
var someobject = jsonrpc.lookup("someobject");
someobject.doSomething();

I've ommitted async in the example for clarity. We could either make it
sync or async.

If we took the async approach it would as a by product remove the
synchronous listMethods when constructing the client (which you probably
notice there is a constructor callback in there now so this can be done
async) as this could be done in lookup. We can still eagerly fetch the
methods for all exported obejcts to avoid roundtrips (so a successive
lookup would not go to the server).

so async with this approach we would have:

var cb = function(someobject, error)
{
if(someobject) someobject.doSomething();
else reportError(error);
}
jsonrpc.lookup(cb, "someobject");

Although it would be a pain to chain all these callbacks if you have a
lot of server objects exported.

You could take a sync approach (in the first example) but you would
still need the callback in the Client constructor to fetch the exported
objects/methods.

From what I see in the discussions I'm sure you are thinking along
these same lines?

~mc

[arthur...@gmail.com]

I would say, make an Issue in the issue tracker-- let's not let these
ideas escape us!