Path

ez projects / ezjscore / forum / general / evolution of the extension...


evolution of the extension - usage of standard rpc protocols

You need to be logged in to post messages in the forums. New users may register here.

Gaetano Giunta

Member since:
30 November 1999

Posts: 269

Thursday 24 September 2009 2:49:39 pm

I think this could be more useful if it accepted 'standard' rpc protocols, namely json-rpc and xml-rpc.
There are basically 2 reasons for this:
- ajax user interfaces are not forced to use the yui/jquery js classes provided with the lib to make calls to exposed functionality
- non-ajax clients abound that would be immediately able to take advantage of the exposed functionality
In an ideal world, we would even be able to register old code, currently developed to be exposed as soap methods within edZP into the jscore extension.
Is anybody interested in this?

Principal Consultant International Business
Member of the Community Project Board

Up

André R

Member since:
20 August 2005

Posts: 171

Thursday 24 September 2009 4:04:24 pm

Could you elaborate a bit more on it, especially json-rpc.
Especially what kind of requirements it has for client / server side, if one need external libs for it or things like that, how you pass parameters from client to server and what kind of format it returns.

--
ar

Up

Gaetano Giunta

Member since:
30 November 1999

Posts: 269

Thursday 24 September 2009 9:59:50 pm

About json-rpc: the spec is here: http://json-rpc.org/

Version 1 is the stable version of the spec - basically copied from xml-rpc but using json notation instead of xml and adding a concept of bidirectional communication that never really took of, as most implementations are http-bound.

Version 2 adds quite a few features and clarifications, but has been in the works for a very long time without getting to final state. As such, it is not widely implemented.

To parse it, you just need to json-decode the POST payload and make sure that it conform to a standard format.

I have been thinking more about the current state of webservice support, and I think a better option could be not to try to shoehorn everything into ezjscore, but to allow it to integrate with ggwebservices - that already has support for all those protocols.

Basically ggwebservices also provides some module-view that allows php functions to be registered and the results to be served to the caller using the protocol he specified.
Two things are missing:
- allow that module to register the php functions the same way that ezjscore does register them (and do the policy check too)
- verify that index_ajax.php can be used to serve it

Principal Consultant International Business
Member of the Community Project Board

Up

Gaetano Giunta

Member since:
30 November 1999

Posts: 269

Friday 25 September 2009 12:37:12 am

Support for executing ezjscore-registered methods from ggws executor view checked in in svn rev. 102
- not tested yet
- support for introspective methods and multicall methods not there yet

nb: xmlrpc has a gamut of system methods defined in the protocol spec - it would be nice if the ezjscServerRouter could, beside creating an obj instance if there is a provider for a given received call:
a - list registered methods
b - provide a description of registered methods params and goal

Principal Consultant International Business
Member of the Community Project Board

Up

Gaetano Giunta

Member since:
30 November 1999

Posts: 269

Saturday 03 October 2009 12:47:21 am

I tested (and fixed) support for executing ezjscore methods via xmlrpc / jsonrpc calls (passing trough webservices/execute view) today. A new release of ggwebservices is pending.

Still waiting for ezjscore to provide via api the list of implemented methods (using reflection to build it?) and a short description of them...

Principal Consultant International Business
Member of the Community Project Board

Up

André R

Member since:
20 August 2005

Posts: 171

Monday 05 October 2009 11:08:20 am

Well then you'll have to wait a bit, 1.1 / 2.0 won't be out before 4.3 is out.

--
ar

Up

Gaetano Giunta

Member since:
30 November 1999

Posts: 269

Thursday 29 October 2009 12:41:46 pm

Some more food for thought:

the current Y.io.ez function is (imho) severely lacking.

Problems:

1 - even though it uses POST by default (which is good, as webservices that modify data should never be accessed via GET), the standard way to add params to the call is to append them to the url, eg myclass::method::p1::p2. This means that those params get written in server logs, which is bad for security-sensitive params

2 - to avoid passing params in the url, the current approach is to use the 'data' member of the config object provided to Y.io.ez(). The problem are that a) it does not follow a standard, everybody is free to use its preferred format for those, and b) that data is not passed to the php code implementing the ajax call backend - it has to retrieve it via access to $_POST, which is very bad for interoperability - that code should only use the stuff it gets as array as 1st param of the php function

3 - when specifying parameters using the :: separator, there is no js code available to escape strings containing the separator token itself. As far as I could gather, there is no code to de-escape it on the backend, either

4 - last but not least, trying to use a / or \ char in the params in the url brought me to error 404 pages from apache (to be investigated further)

5 - usage of POST is forced anyway, even if in the config object the coder specifies GET. get should be fine for methods that retrieve data without modifying it, and the coder should be able to specify he wants to use it (if he knows what he's doing)

Proposal:
a - alter the Y.io.ez function to make it more flexible and robust, while at the same time keeping the existing functionality (but marking it somehow deprecated). In this case the backend ezjscore/call module must be updated to be compatible with the different syntaxes.
b - create a new function and mark the existing one deprecated. It can point to a different module/view, so a new view can be created which does not need to keep backward compatibility

API for the new function: Y.io.ez( method, params=[], config={})

Logic:
- by default a POST is issued. In this case, the params are encoded in the req body
- params are encoded in body in Json format. config obj can specify a different encoding (form/urlencoded or php serialized come to mind)
- if config specifies GET method, params are encoded in the url instead of the body. either the standard jscore :: separator is used, or a json serialization (which is better as it can be escaped/deescaped automatically)

Principal Consultant International Business
Member of the Community Project Board

Up

Gaetano Giunta

Member since:
30 November 1999

Posts: 269

Thursday 29 October 2009 2:50:18 pm

btw, function similar to Y.io.ez that uses jsonrpc available: http://websvn.projects.ez.no/wsvn...ices_design_standard_javascript_yui_

Principal Consultant International Business
Member of the Community Project Board

Up

You need to be logged in to post messages in the forums. New users may register here.