James Britt
3/1/2005 12:06:00 AM
Jacob Fugal wrote:
> ...
> Thanks, James, this is awesome. I've been playing with it a bit today
> (after getting past the packaging issues, which I know you're already
> aware of) and have been quite impressed.
Thanks. I hope to have another version out tonight or tomorrow.
>
> The one hangup I've seen is that the jsonrpc.js library you included
> doesn't seem to allow for asynchronous requests. This limits a few
> things (e.g. if the request has a delay in either transit or server
> side processing, that delay still blocks the user, though nowhere near
> as much as a full page refresh) but can be worked around by tweaking
> the jsonrpc.js library.
Yes, the lack of async is a problem. The other thing I'm unhappy about
is that the dynamically created client objects hang off the jsonrpc
object. So, if the server expose foo.bar, the client needs to call
jsonrpc.foo.bar, rather than simply foo.bar. But I see any reasons
this has to be; after the initial call to listServices the client should
be able to just build the corresponding client objects independently.
One thing that appealed to me about that particular jsonrpc script,
though, was the idea that one could simply swap out server
implementations with clients being none the wiser. And I somehow got
the impression that this Java library JavaScript was following some sort
of known convention. But that could be completely wrong. Might be
worth seeing what people in PHP land do, for example, steal ideas from
there, too.
Anyway, that part should be independent of the server code; one should
be able to use any number of JavaScript client scripts (implementing
json-rpc), all according to what works best for the application.
Thanks,
James