On Tue, Aug 30, 2011 at 03:13, Tristan Koch <[email protected]> wrote:
> > No, that's an incorrect assumption. JSON-RPC services are intended to
> return an error instead of a result whenever something can not be
> accomplished as requested. That might be anything like "Permission denied"
> or "Transaction timed out" or "Resource unavailable" or "No such result". It
> is perfectly normal for an error response to be returned.
>
> I see. "Cannot be accomplished as requested…", so it kind of relates to
> exceptions?
It can be thought of as an exception, or even as the equivalent of returning
-1 from a Linux function and setting errno with the details of the error.
> Referring to the examples you gave, what would be a typical error result?
>
Here's a representative response:
{
jsonrpc : "2.0",
id : 42,
error :
{
code : myApp.ErrorCodes.PERMISSION_DENIED,
message : "Permission denied",
data : "This procedure requires that you be logged in."
}
}
>
> > A JSON-RPC error and a JSON-RPC result are both sent as normal JSON data.
> I kept them together as a distinction with a transport ("failed") error. I
> don't have a strong opinion, though, that the two must not be separated even
> in the low-level Rpc class. I separated them in the Coalesce class, and if
> there's a consensus to separate them in Rpc, I'd gladly do that.
>
> Perhaps, a good compromise is to offer a generic event that signals a
> response (close to what "load" is in io.request) as well as events for a
> "success" and "error" result.
>
I'd have no problem with that. We can fire one event in both cases, and
separate events for the two different cases, and let the developer listen
for whichever is desired.
> > I was looking at rest.Resource as I initially worked on this, and
> couldn't figure out why you had created a separate event type for it. To me,
> that just increases the complexity because one needs to look up the API for
> a different event type, rather than always knowing to call getData(). What
> is the benefit of creating a new event type? Maybe I'm missing some
> conceptual advantage?
>
> I guess its a matter of style and maybe we should have thought about it
> twice. I follow your argument about added complexity. When I made the
> decision, it seemed alien to access properties directly (no getter).
> However, rest.Resource is still experimental, so I don't object to make
> changes here to accomplish better consistency.
>
If there are many unique properties of an event, or if it will be widely
used, I can see it making sense to add a new event type. Having a Mouse
event that is more than a simple Data event makes sense to me. I'm really
not sure I can see a benefit in either the rpc nor rest case. A simple Data
event seems more appropriate to me for both.
> > I'm certainly planning on creating a test infrastructure. Unit tests may
> not be appropriate for this (although I'll look at what you did for
> rest.Resource to see if unit tests make sense). I intend to create a working
> example and test code, using RpcJs' transport simulator, so that full RPC
> round-trips can be accomplished within the browser. I will likely also
> create a Rhino-based RpcJs JSON-RPC Version 2 test server, to ensure that it
> works with the Xhr transport too.
>
> I would really welcome it if you came to the conclusion that unit tests
> make sense. You can see in test...resource, its possible to inject a
> synthetic request (a fake double) you can instruct to fire whatever events
> you want your code to test against. This way, you test your code insolation.
> You can also offer a fake server (using MMock) that responds to Xhr
> requests. Maybe, lets work together on this? Also, I'm planning to add a
> section about MMock to the manual with usage examples.
>
I've been wanting to learn more about MMock anyway, so maybe this is my
opportunity.
I'd planned on having a couple of days after vacation but before school
started again, to work on this, and those days have been taken up by my
flight cancellation/reschedule. I'll have to see when/how I can schedule
this work in now. :-(
Cheers,
Derrell
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
