On Nov 27, 2009, at 14:57 , panyasan wrote: > > Hi, > Hi,
> this is mainly to Derrell, Victor, Andreas and Nick as authors of the PHP, > Python, Java and Perl JSON-RPC Backends, but also to anyone else with an > interest in the json-rpc backends. I'm interested since I had to hack, quite a lot, the RPC-Java to fit my needs and I had already discussed here our will to propose to the community a entirely refactored version or a another possible Java-RPC implem. I'm only talking about the server side as we found the client side perfectly fit our needs. Quickly, the hack I had to do allows more ways to be able to customize the global rpc process on server side, typically, before of after serialisation. Basically, we found that serialization and call to the controller was too much intricated. The refactor I'm thinking about is a way to give back to the community a RPC-Java where serialization and generic call to the controller is clearly separated and a more modern version that take into account Java annotation to specify the attributes that should/should not be part of the serialization. I have to warn that we are under high pressure here and this contribution will not be available in the next hours :-) I'm thinking about months. > These backends are quite diverse in > implementation, documentation, and development status: > > http://qooxdoo.org/documentation/0.8/rpc_perl > http://qooxdoo.org/documentation/0.8/rpc_java > http://qooxdoo.org/documentation/0.8/rpc_php > http://qooxdoo.org/documentation/rpc_python > > and I wonder if we should not try and make an effort to present a more > coherent and better documented backend experience before the 1.0 release. I > think the following points would be salient: > > 1) Implementation > > If you look through the individual implementations, they have quite > different ways of actually invoking the service methods. This is due to > language specificities and to the different ways the servers work (Script > vs. standalone server vs. servlet container). However, I think some effort > could be made to offer a more uniform way of implementation which allows > users to switch backends more easily. This also touches some points Burak > has recently made concerning his SOAP backend. I do not agree. This will ends up with bad implementation in all language in a desperate and impossible try to make all implementation the same regardless of the languages differences. I'm afraid it is just normal that implem differs. API and protocols should be strictly shared to allow to switch implementation. Do you mean currently, it is not possible to simply switched from a PHP backend to a Java backend using RPC-PHP and then RPC-Java ? About SOAP, I do think this is something qooxdoo should have, since it is a standard, but I don't like it personally. I found it messy and verbose and I do prefer Json. So, please, stick to Json as the default choice and make SOAP a possible option if you really wanted to. I guess this should have impact on client side to make SOAP call. > > 2) Devolopment status > > It would be great if all backends could have a stable release accompanying > the qooxdoo 1.0 release. The java backend seems to be stable and in > production, PHP has a stable release but also a trunk that is ready for > release (but could also still be changed in some respects as far as point 1) > is concerned). RpcPython certainly needs more testing and is also > conceptually not yet 1.0. I don't know about the state of the Perl backend. > > 3) Documentation > > Well, let's say, the current state of documentation is sketchy at best (just > click and see). I agree. I had to find my way in the code and despite a very common mistake, code is not the doc :-) So, I found the learning curve could be improved. > Here, too, some coordination and common structure would > certainly help users. Also, documentation should move out of the > "documentation/0.8/" namespace and either into its own > "documentation/backend" section or into the "contrib" section, since the > servers do not move with the versioning of qooxdoo, as long as the json-rpc > protocol doesn't change (that's the beauty of it all). > > We could discuss this here on the list or move off-list in case it is not of > general interest. > > Cheers, > > Christian > -- > View this message in context: > http://n2.nabble.com/Rpc-backend-harmonization-tp4075821p4075821.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 > ------------------------------------------------------------------------------ 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
