Hello Derrell,

Derrell Lipman wrote:
> 
> - In this rpc page (as in the older page from which much of this content
> was
> derived), script transport is not discussed. It should be mentioned in the
> Transport section, and importantly, the required call to to the qooxdoo
> method from the backend code should be described.
> 
> - In this rpc page, I'd like to remove the following requirements from the
> transport spec:  sink, sleep. These were part of my very early PHP backend
> testing, they do not really add anything of value, and they are not used
> in
> the RpcExample test suite.
> 
> - Also in this rpc page, I'd like to remove the requirement of the
> getParams() test. Having that test encourages implementors to pass the
> array
> of parameters to the methods rather than expanding the array as the
> invoked
> method parameter list. Some languages do not support variable argument
> lists, and the getParams() test requires implementing multiple getParams()
> methods in the test code to support the multiple tests of varying argument
> list length. As an alternative, if there is some feeling that this method
> provides a useful test, I'd propose that it be replaced with get4Params()
> which always expects and returns its four parameters, but I really don't
> think such a thing is necessary. We already test returning an array (both
> of
> integers and of strings).
> 

Please go ahead and apply the neccessary changes, I don't think any of the
server authors will object.


Derrell Lipman wrote:
> 
> - In the jsonrpc_extensions page, It's important, I think, to describe the
> externally-visible operation of the extension in addition to how to test
> whether the extension exists. As an example, let's say I see that there is
> an extension for reflection. Great, I say, and I now know how to test
> whether reflection is supported by the server, but not how  to use the
> reflection API, i.e. what methods are provided if this extension is
> available, and what are those methods' signatures.
> 

What about returning a property "specServices" which is an array of service
names provided by the capability / feature? Then, if introspection is
enabled, thes services can be further queried for method names and
signatures?

C.

-- 
View this message in context: 
http://n2.nabble.com/Rpc-backend-harmonization-tp4075821p4083311.html
Sent from the qooxdoo mailing list archive at Nabble.com.

------------------------------------------------------------------------------
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

Reply via email to