> MRpcMockup:
> - comfortable
> - tight coupling
> - relies on Rpc internals (unreliable interface)
> - only for ad-hoc, interactive usage
>
>
So, saving rpc traffic data to file is there, but I see you only capture
the response data. I'm not sure this is sufficient. You pick up
responses in the mockup mode by going through the hash of the rpc
signature (prob. over something like service-name/params), right?! But
the request signature is only captured as comments. I think it would be
better a part of the generated Json. Capture data should be
self-contained, to the extend that a single Json key (the request hash,
if you will) contains subkeys "request" and "response" that represent
both sides of the request in a standardized why. I think this would be
way more useful.
The Json file format should also allow for more than one request per
file. This is probably nothing you could support on the capturing side,
but would be done by hand. But the replay facility should be able to
handle this, so you can pass, say, 1,000 requests within a single file.
Something like this:
{
"deb693849aab654cde5261a77ae8c0f41943dc60":
{
"request" :
{
"serverUrl" : "http://.../RpcPhp/1.0.1/services/index.php";,
"serviceName" : "qooxdoo.test",
"serviceMethod" : "echo",
"params" : ["Hello World"],
"serverData" : null
},
"response" :
{
"id" : 4711,
"error" : null,
"response" : "Client said: [Hello World]"
}
},
"x5z693849aab654cde5261a77ae8c0f41943dc60":
{
"request" : ...,
"response" : ...
},
...
}
T.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
