Rpc* backend "harmonization"

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Rpc* backend "harmonization"

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

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). 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
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

oetiker
Hi Christian,

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

I have taken over from Nick as maintaier of the perl backend, we
use it in production ... I will be glad to term it 1.0 for the 1.0
qooxdoo release ...

As for your unification idea ... I am actually looking at going
into the oposite direction, my ideal situation would be that each
backend follows the 'natural' way things are done in the respective
language ... (the perl backend is not ideal in this respect yet
btw). Why have different language support when it is only
half hearted by pushing a paradigm on a language which does not
match its way of dealing with web-services.

I am looking at maybe using Mojo as a basis for a future/alternate
version of the backend, but for now I am quite happy with the state
the perl backend is in ... (is actualy anyone besides us here at
O+P using this ?

cheers
tobi

--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch [hidden email] ++41 62 775 9902 / sb: -9900

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

Jean-Baptiste BRIAUD -- Novlog
In reply to this post by panyasan

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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

panyasan
Jean-Baptiste BRIAUD -- Novlog wrote
> 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.
Since you're also making this point, I want to make myself clear: I did not mean to force a paradigm on all implementations regardless of language. What I meant was implementing a common set of behaviors - for example, introspection comes to my mind, or security - or ways of designing the API, the documentation , the method signature, etc., all things that can be implemented one was or another regardless of language. I think there are allways at least two ways things can be implemented in a language "naturally", and I would think it was better for users if they are similar across implementations. But this is certainly not a No. 1 priority - just a "would-be-nice" thing to keep in mind.

Jean-Baptiste BRIAUD -- Novlog wrote
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 ?
It is as simple or as difficult as the developer's skills, I guess ;-)  - My point concerned more the way a new user would look at the backends and say: "Ok, for this particular task, this backend is more suited than the others", and some conceptual similarity certainly helps in deciding this question.

But as I said, the streamlining of implementations is certainly not the key issue here.

C.

Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

Derrell Lipman
In reply to this post by panyasan
On Fri, Nov 27, 2009 at 08:57, panyasan <[hidden email]> wrote:

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. These  backends are quite diverse in
implementation, documentation, and development status:

Hi Christian,

I'm really glad you've recently been taking the lead on organization of backends! It's really useful to have someone leading the charge. Thank you!

Way back when, I wrote the Backend Developers' Guide to assist others in implementing "conforming" backends, and the RpcExample tests to "prove" conformance. Since then there have been some minor extensions to some of the backends, e.g. only the PHP backend supports the Remote Table example and there is a second Error test for thrown vs returned errors, but essentially the common functionality remains. All backends support what's in the Developers' Guide and tested by the basic RpcExample tests. I believe this is all that is "required" from a commonality point of view. Each backend should be free, IMO, to use best practices in the implementation language without regard to implementation details of other languages.

There is certainly room for expansion of the original "specification" in the Developers' Guide, and introspection is a very reasonable addition. Since all of the key players are involved in this discussion already, you might describe what you've implemented in that regard in the PHP backend to see if it is feasible to implement in the other backends.

I definitely agree on the need for documentation improvement!

Derrell


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

panyasan
Hello Derrell,

Derrell Lipman wrote
Way back when, I wrote the Backend Developers' Guide to assist others in
implementing "conforming" backends, and the RpcExample tests to "prove"
conformance. Since then there have been some minor extensions to some of the
backends, e.g. only the PHP backend supports the Remote Table example and
there is a second Error test for thrown vs returned errors, but essentially
the common functionality remains. All backends support what's in the
Developers' Guide and tested by the basic RpcExample tests. I believe this
is all that is "required" from a commonality point of view. Each backend
should be free, IMO, to use best practices in the implementation language
without regard to implementation details of other languages.
Yes, this is certainly the way to go. No matter how the backend is functioning internally, the behavior should be exactly the same from the perspective of the qooxdoo (or any other javascript-based) application on the client. And this is why a test suite like RpcExample is so important. This is what we should concentrate on and where I think all backend implementators can agree on. Your server-writing-guide (http://qooxdoo.org/documentation/0.8/rpc_server_writer_guide) should be the basis of that.

Here are some suggestions:

- The "Server writer guide" should be made a "Standard"
- There should be a clear normative "core" (obligatory to pass the standard) and optional "extensions"
- We should create a page with "proposals" to this standard (core / extensions) and then discuss the pros and cons of the proposals together.

Derrell Lipman wrote
There is certainly room for expansion of the original "specification" in the
Developers' Guide, and introspection is a very reasonable addition. Since
all of the key players are involved in this discussion already, you might
describe what you've implemented in that regard in the PHP backend to see if
it is feasible to implement in the other backends.
I would do that as an extension proposal. However, there should be one "core" feature that allowed to query the server whether a certain extension is available.

Best, Christian

BTW the page http://qooxdoo.org/documentation/RPC is referenced in various places in the wiki but doesn't exist.
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

Derrell Lipman
On Fri, Nov 27, 2009 at 10:44, panyasan <[hidden email]> wrote:


Yes, this is certainly the way to go. No matter how the backend is
functioning internally, the behavior should be exactly the same from the
perspective of the qooxdoo (or any other javascript-based) application on
the client. And this is why a test suite like RpcExample is so important.
This is what we should concentrate on and where I think all backend
implementators can agree on. Your server-writing-guide
(http://qooxdoo.org/documentation/0.8/rpc_server_writer_guide) should be the
basis of that.

I had mis-remembered the name. Yes, that's what I referred to when I discussed the Developers' Guide.

Here are some suggestions:

- The "Server writer guide" should be made a "Standard"
- There should be a clear normative "core" (obligatory to pass the standard)
and optional "extensions"
- We should create a page with "proposals" to this standard (core /
extensions) and then discuss the pros and cons of the proposals together.

Sounds fine. The normative "core" is, I think, what's currently in that document, with the possible addition of:
 


Derrell Lipman wrote:
>
> There is certainly room for expansion of the original "specification" in
> the
> Developers' Guide, and introspection is a very reasonable addition. Since
> all of the key players are involved in this discussion already, you might
> describe what you've implemented in that regard in the PHP backend to see
> if
> it is feasible to implement in the other backends.
>

I would do that as an extension proposal. However, there should be one
"core" feature that allowed to query the server whether a certain extension
is available.

Agreed. A qxServer.hasFeature(String featureName) method or something of that sort would be appropriate I suppose. We might end up with other qxServer.* methods, such as the introspection. (I'm not at all wed to that name nor even to containing them in a single Class (in PHP terminology. We can discuss how to make the hasFeature request.)

Derrell


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

Vincent Vandenschrick
Hi all,

Regarding RPC backends, there is another point that I would like to
raise to your attention. My use of RpcJava with latest Qooxdoo releases
forced me to change the codebase to make it work. This is due to API
change (e.g. qx.io.ScriptTransport removed in 1.0-beta1, after a
deprecation period).
Identifying and fixing the code is not a problem by itself, but how to
maintain it, i.e. what should go into SVN ? If we check-in the change,
it breaks pre-0.8 implementations, and if we don't, then it doesn't work
with 1.0+.


I see 2 main options (variations could be made) :

* keep a single SVN branch (the trunk) but introduce an indirection
through some strategy/delegation pattern to isolate the code that is
tightly coupled to the Qooxdoo version of the client-side (the
server-side JS generation). Then find a way to instanciate the good
strategy based on the Qooxdoo version :
  - automatically : if there is a way for the client to send its Qooxdoo
version when initiating the communication. This would enable support for
heterogenous Qooxdoo clients within the same server.
  - by external configuration : at server startup (e.g. a servlet
parameter for RpcJava, don't know for others). Easier but less flexible
than the previous one, i.e. only 1 Qooxdoo version supported per server
instance.

* setup a clean and uniform branching/tagging policy for contributions.
This is true for RpxcXxx but somehow even more important for Qooxdoo
contribs that are to be included in the build using the "contrib:/" URL
scheme. Linking to a contrib trunk is dangerous, especially when the
contribution is quickly evolving and follows the latest Qooxdoo API.
This makes the builds of a Qooxdoo app not reproductible and a good
branching/tagging policy would at least solve this problem.

BTW, find attached the SVN patch applied to my local RpcJava check-out
to make it 1.0-beta1 compliant.

Best,
Vincent

Index: rpc/net/sf/qooxdoo/rpc/RpcServlet.java
===================================================================
--- rpc/net/sf/qooxdoo/rpc/RpcServlet.java (revision 19559)
+++ rpc/net/sf/qooxdoo/rpc/RpcServlet.java (working copy)
@@ -204,13 +204,15 @@
                                         propertyType));
                         } catch (Exception e) {
                             // try to instatiate a class of the supplied parameter
-                            System.out.println("***** setting '" + propertyName + "' to an instance of '" + initParamValue + "'");
+                            // System.out.println("***** setting '" + propertyName +
+                            // "' to an instance of '" + initParamValue + "'");
                             PropertyUtils.setSimpleProperty(inst, propertyName,
                                     getServiceInstance(session, initParamValue, null, null));
                         }
                     }
                 } else {
-                    System.out.println("***** property '" + propertyName + "' not matched");
+                  // System.out.println("***** property '" + propertyName +
+                  // "' not matched");
                 }
             }
 
@@ -269,7 +271,7 @@
     
     private String makeJavaScriptServerInfo(HttpServletRequest request) {
         return "if (!qx || !qx.core || !qx.core.ServerSettings) {" +
-                 "qx.OO.defineClass(\"qx.core.ServerSettings\");" +
+                 "qx.Class.define(\"qx.core.ServerSettings\");" +
                 "}" +
                 "qx.core.ServerSettings.serverPathPrefix = \"" + getContextURL(request) + "\";" +
                 "qx.core.ServerSettings.serverPathSuffix = \";jsessionid=" + request.getSession().getId() + "\";" +
@@ -407,7 +409,7 @@
                     //System.out.println("Requested session id: " + request.getRequestedSessionId());
                     String res = handleRPC(request, requestString);
                     
-                    responseWriter.write("qx.io.remote.ScriptTransport._requestFinished(\"" +
+                    responseWriter.write("qx.io.remote.transport.Script._requestFinished(\"" +
                             jsTransportId + "\", " + res + ");");
                 }
             } catch (Exception e) {
@@ -460,7 +462,7 @@
                     requestBuffer.append(readBuffer, 0, length);
                 }
                 String requestString = requestBuffer.toString();
-                System.out.println("Request string: " + requestString);
+                // System.out.println("Request string: " + requestString);
                 res = handleRPC(request, requestString);
             }
             

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

panyasan
Hi all,

not being a java person, it seems nontheless imperative to me that an updated and unified Java backend, together with some decent and up-to-date docs should accompany the qooxdoo 1.0 release. Everything else - at least that would be my impression - would be unfortunate and unneccessarily deterrent for first-time qooxdoo/java users.

If have moved some java documentation from

http://qooxdoo.org/documentation/0.8/rpc

to

http://qooxdoo.org/documentation/0.8/rpc_java

but I don't know if the code there still applies.

Can someone look into it and fix the documentation?

Other than that, it would be great if the code of the Java servlet could be updated, too - who is in charge here? ;-)

Thanks,

Christian

Vincent Vandenschrick wrote
Hi all,

Regarding RPC backends, there is another point that I would like to
raise to your attention. My use of RpcJava with latest Qooxdoo releases
forced me to change the codebase to make it work. This is due to API
change (e.g. qx.io.ScriptTransport removed in 1.0-beta1, after a
deprecation period).
Identifying and fixing the code is not a problem by itself, but how to
maintain it, i.e. what should go into SVN ? If we check-in the change,
it breaks pre-0.8 implementations, and if we don't, then it doesn't work
with 1.0+.


I see 2 main options (variations could be made) :

* keep a single SVN branch (the trunk) but introduce an indirection
through some strategy/delegation pattern to isolate the code that is
tightly coupled to the Qooxdoo version of the client-side (the
server-side JS generation). Then find a way to instanciate the good
strategy based on the Qooxdoo version :
  - automatically : if there is a way for the client to send its Qooxdoo
version when initiating the communication. This would enable support for
heterogenous Qooxdoo clients within the same server.
  - by external configuration : at server startup (e.g. a servlet
parameter for RpcJava, don't know for others). Easier but less flexible
than the previous one, i.e. only 1 Qooxdoo version supported per server
instance.

* setup a clean and uniform branching/tagging policy for contributions.
This is true for RpxcXxx but somehow even more important for Qooxdoo
contribs that are to be included in the build using the "contrib:/" URL
scheme. Linking to a contrib trunk is dangerous, especially when the
contribution is quickly evolving and follows the latest Qooxdoo API.
This makes the builds of a Qooxdoo app not reproductible and a good
branching/tagging policy would at least solve this problem.

BTW, find attached the SVN patch applied to my local RpcJava check-out
to make it 1.0-beta1 compliant.

Best,
Vincent

Index: rpc/net/sf/qooxdoo/rpc/RpcServlet.java
===================================================================
--- rpc/net/sf/qooxdoo/rpc/RpcServlet.java (revision 19559)
+++ rpc/net/sf/qooxdoo/rpc/RpcServlet.java (working copy)
@@ -204,13 +204,15 @@
                                         propertyType));
                         } catch (Exception e) {
                             // try to instatiate a class of the supplied parameter
-                            System.out.println("***** setting '" + propertyName + "' to an instance of '" + initParamValue + "'");
+                            // System.out.println("***** setting '" + propertyName +
+                            // "' to an instance of '" + initParamValue + "'");
                             PropertyUtils.setSimpleProperty(inst, propertyName,
                                     getServiceInstance(session, initParamValue, null, null));
                         }
                     }
                 } else {
-                    System.out.println("***** property '" + propertyName + "' not matched");
+                  // System.out.println("***** property '" + propertyName +
+                  // "' not matched");
                 }
             }
 
@@ -269,7 +271,7 @@
     
     private String makeJavaScriptServerInfo(HttpServletRequest request) {
         return "if (!qx || !qx.core || !qx.core.ServerSettings) {" +
-                 "qx.OO.defineClass(\"qx.core.ServerSettings\");" +
+                 "qx.Class.define(\"qx.core.ServerSettings\");" +
                 "}" +
                 "qx.core.ServerSettings.serverPathPrefix = \"" + getContextURL(request) + "\";" +
                 "qx.core.ServerSettings.serverPathSuffix = \";jsessionid=" + request.getSession().getId() + "\";" +
@@ -407,7 +409,7 @@
                     //System.out.println("Requested session id: " + request.getRequestedSessionId());
                     String res = handleRPC(request, requestString);
                     
-                    responseWriter.write("qx.io.remote.ScriptTransport._requestFinished(\"" +
+                    responseWriter.write("qx.io.remote.transport.Script._requestFinished(\"" +
                             jsTransportId + "\", " + res + ");");
                 }
             } catch (Exception e) {
@@ -460,7 +462,7 @@
                     requestBuffer.append(readBuffer, 0, length);
                 }
                 String requestString = requestBuffer.toString();
-                System.out.println("Request string: " + requestString);
+                // System.out.println("Request string: " + requestString);
                 res = handleRPC(request, requestString);
             }
             

------------------------------------------------------------------------------
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
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

panyasan
In reply to this post by Derrell Lipman
Hi Derrell,

Derrell Lipman wrote
Agreed. A qxServer.hasFeature(String featureName) method or something of
that sort would be appropriate I suppose. We might end up with other
qxServer.* methods, such as the introspection. (I'm not at all wed to that
name nor even to containing them in a single Class (in PHP terminology. We
can discuss how to make the hasFeature request.)
I'd prefer "getCapabilities", to be closer to the  established XML-RPC API method ( http://xmlrpc-c.sourceforge.net/introspection.html ). What do you think?

Christian
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

Jean-Baptiste BRIAUD -- Novlog

On Nov 28, 2009, at 12:44 , panyasan wrote:

>
> Hi Derrell,
>
>
> Derrell Lipman wrote:
>>
>> Agreed. A qxServer.hasFeature(String featureName) method or something of
>> that sort would be appropriate I suppose. We might end up with other
>> qxServer.* methods, such as the introspection. (I'm not at all wed to that
>> name nor even to containing them in a single Class (in PHP terminology. We
>> can discuss how to make the hasFeature request.)
>>
>
> I'd prefer "getCapabilities", to be closer to the  established XML-RPC API
> method ( http://xmlrpc-c.sourceforge.net/introspection.html ). What do you
> think?

Could one explain to me why this kind of method is needed ?
How this method will be used ?

>
> Christian
>
> --
> View this message in context: http://n2.nabble.com/Rpc-backend-harmonization-tp4075821p4079277.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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

Gene Amtower
In reply to this post by Vincent Vandenschrick
One other option is to roll the backends INTO the Qooxdoo framework distribution so that they are always supplied with the appropriate Qooxdoo version - why do they need to be kept as contributions?  From time to time, contributions are combined into the Qooxdoo mainstream distribution, aren't they?

It seems the coupling between the client and backend components is critical enough that they should be supplied together when a developer retrieves Qooxdoo.  In the case of the backends, all the developers are participants on this mailing list.  Just create an additional folder in the distribution for backend servers and dump them all into Qooxdoo.  Since the backend development is maintained by various Qooxdoo developers in parallel with the Qooxdoo client development path, this allows the matching backend code to be kept in sync at all times.  The only time a contribution arrangement is required is when a new backend server is being developed and needs incubation time to become production-ready.  Once they are being used in production situations, it makes sense to provide them with the Qooxdoo framework.

Along the same lines, maybe it's time for the RpcExample and RpcConsole to also become a part of the Qooxdoo distribution.  All of these components related to development of Qooxdoo apps that depend on a server backend are becoming more important for developing just about any mainstream web app - how many of us are developing client apps without any type of backend component?

Are there more pressing reasons to keep the backend components separate from the client framework?  How much would this grow the framework size?

Just my 2 cents,

   Gene

On Sat, 2009-11-28 at 08:20 +0100, Vincent Vandenschrick wrote:
Hi all,

Regarding RPC backends, there is another point that I would like to 
raise to your attention. My use of RpcJava with latest Qooxdoo releases 
forced me to change the codebase to make it work. This is due to API 
change (e.g. qx.io.ScriptTransport removed in 1.0-beta1, after a 
deprecation period).
Identifying and fixing the code is not a problem by itself, but how to 
maintain it, i.e. what should go into SVN ? If we check-in the change, 
it breaks pre-0.8 implementations, and if we don't, then it doesn't work 
with 1.0+.


I see 2 main options (variations could be made) :

* keep a single SVN branch (the trunk) but introduce an indirection 
through some strategy/delegation pattern to isolate the code that is 
tightly coupled to the Qooxdoo version of the client-side (the 
server-side JS generation). Then find a way to instanciate the good 
strategy based on the Qooxdoo version :
  - automatically : if there is a way for the client to send its Qooxdoo 
version when initiating the communication. This would enable support for 
heterogenous Qooxdoo clients within the same server.
  - by external configuration : at server startup (e.g. a servlet 
parameter for RpcJava, don't know for others). Easier but less flexible 
than the previous one, i.e. only 1 Qooxdoo version supported per server 
instance.

* setup a clean and uniform branching/tagging policy for contributions. 
This is true for RpxcXxx but somehow even more important for Qooxdoo 
contribs that are to be included in the build using the "contrib:/" URL 
scheme. Linking to a contrib trunk is dangerous, especially when the 
contribution is quickly evolving and follows the latest Qooxdoo API. 
This makes the builds of a Qooxdoo app not reproductible and a good 
branching/tagging policy would at least solve this problem.

BTW, find attached the SVN patch applied to my local RpcJava check-out 
to make it 1.0-beta1 compliant.

Best,
Vincent
plain text document attachment (RpcJava-1.0beta1-patch.txt)
Index: rpc/net/sf/qooxdoo/rpc/RpcServlet.java
===================================================================
--- rpc/net/sf/qooxdoo/rpc/RpcServlet.java	(revision 19559)
+++ rpc/net/sf/qooxdoo/rpc/RpcServlet.java	(working copy)
@@ -204,13 +204,15 @@
                                         propertyType));
                         } catch (Exception e) {
                             // try to instatiate a class of the supplied parameter
-                            System.out.println("***** setting '" + propertyName + "' to an instance of '" + initParamValue + "'");
+                            // System.out.println("***** setting '" + propertyName +
+                            // "' to an instance of '" + initParamValue + "'");
                             PropertyUtils.setSimpleProperty(inst, propertyName,
                                     getServiceInstance(session, initParamValue, null, null));
                         }
                     }
                 } else {
-                    System.out.println("***** property '" + propertyName + "' not matched");
+                  // System.out.println("***** property '" + propertyName +
+                  // "' not matched");
                 }
             }
 
@@ -269,7 +271,7 @@
     
     private String makeJavaScriptServerInfo(HttpServletRequest request) {
         return "if (!qx || !qx.core || !qx.core.ServerSettings) {" +
-                 "qx.OO.defineClass(\"qx.core.ServerSettings\");" +
+                 "qx.Class.define(\"qx.core.ServerSettings\");" +
                 "}" +
                 "qx.core.ServerSettings.serverPathPrefix = \"" + getContextURL(request) + "\";" +
                 "qx.core.ServerSettings.serverPathSuffix = \";jsessionid=" + request.getSession().getId() + "\";" +
@@ -407,7 +409,7 @@
                     //System.out.println("Requested session id: " + request.getRequestedSessionId());
                     String res = handleRPC(request, requestString);
                     
-                    responseWriter.write("qx.io.remote.ScriptTransport._requestFinished(\"" +
+                    responseWriter.write("qx.io.remote.transport.Script._requestFinished(\"" +
                             jsTransportId + "\", " + res + ");");
                 }
             } catch (Exception e) {
@@ -460,7 +462,7 @@
                     requestBuffer.append(readBuffer, 0, length);
                 }
                 String requestString = requestBuffer.toString();
-                System.out.println("Request string: " + requestString);
+                // System.out.println("Request string: " + requestString);
                 res = handleRPC(request, requestString);
             }
             
------------------------------------------------------------------------------
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 [hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

panyasan
In reply to this post by Jean-Baptiste BRIAUD -- Novlog
Hello Jean-Baptiste,

Jean-Baptiste BRIAUD -- Novlog wrote
Could one explain to me why this kind of method is needed ?
How this method will be used ?
It is a useful method once you move away from creating backends solely for the purpose of servicing a single application, and towards creating webservices that cater to a variety of applications. In my view, this makes it necessary to have at least one method that clients can use to query if a certain behavior/feature is present. An example that I think (and am trying to write) of is a bibliographic citation formatting service. I'll explain more later .
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

Derrell Lipman
In reply to this post by Gene Amtower
Replying to a number of comments without proper attribution...

Christian, I have no problem with getCapabilities() as opposed to hasFeature().

Vincent, 0.7 is old enough that anyone beginning a project requiring a backend _now_ will need one that is 0.8+ compatible. The java backend needs to be updated to the latest and greatest.

Jean-Baptiste, the reason that a hasCapabilities() method is required is that a backend can be used by/for multiple applications. The backend need not be updated on the same schedule as the applications (except for adding the requisite backend methods, of course). This new method allows new applications to determine if the backend is as new as it is, i.e. it has all of the capabilities that it would like to use, or if it must limit its functionality because an older backend is still in use.

And finally:

On Sat, Nov 28, 2009 at 07:20, Gene Amtower <[hidden email]> wrote:
One other option is to roll the backends INTO the Qooxdoo framework distribution so that they are always supplied with the appropriate Qooxdoo version - why do they need to be kept as contributions?

The backends used to be part of the  primary distribution. There were frontend and backend directories, and the current framework directory was a subdir of frontend. The backends have many people working on them who do not have the somewhat more limited-access svn commit rights to the qooxdoo core. Having them as contribs allows for a wider contributing author base.

Also, as stated above, the backends need not be updated at the same times as frontend applications and backends can support many applications (which all need to be retested when the backend core code changes) so the release interval can, and probably should, be different than for the frontend.

Cheers,

Derrell


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

panyasan
Derrell Lipman wrote
Jean-Baptiste, the reason that a hasCapabilities() method is required is
that a backend can be used by/for multiple applications. The backend need
not be updated on the same schedule as the applications (except for adding
the requisite backend methods, of course). This new method allows new
applications to determine if the backend is as new as it is, i.e. it has all
of the capabilities that it would like to use, or if it must limit its
functionality because an older backend is still in use.
... to support Derrell's point and finish my own argument: if a json-rpc backend is used as a general webservice that is queried by more than one application, there must be a way the client application can determine what to expect from the backend. So my proposal would be to add one single service method that returns information on the server's general capabilities, in some ways, the "interfaces" offered by the server. I am thinking along the following lines:

http://qooxdoo.org/documentation/jsonrpc_extensions#getcapabilities

The rationale for this is to offer information not only on the name of the feature, but also its version and an url to more information.

If a server maintainer does not see any need to bother with this, the only thing I would like ask from him/her would be to impement the service method to simply return an empty object ({}), then this would not break the client request.

All other extensions to the core json-rpc server behavior would be completely optional.

Does that make sense to you?

C.
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

panyasan
In reply to this post by Derrell Lipman
Ok, last post for today: here is the summary of my suggestions, wrapped up in one page:

http://qooxdoo.org/documentation/rpc

I'd be very much interested in feedback. I wonder how we should proceed - creating individual bugs and voting on them?

Best,

Christian

Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

Derrell Lipman
On Sat, Nov 28, 2009 at 16:20, panyasan <[hidden email]> wrote:

Ok, last post for today: here is the summary of my suggestions, wrapped up in
one page:

http://qooxdoo.org/documentation/rpc

Nice job! I have only a couple of suggestions on this and your jsonrpc_extensions pages.

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

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

Otherwise, this is looking great!

Derrell


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

panyasan
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.
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

Derrell Lipman
On Sun, Nov 29, 2009 at 11:11, panyasan <[hidden email]> wrote:

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?

That's not what I'm talking about. The server writer needs to know how to implement a conforming implementation of the extension. Without looking at the PHP server, I'd have no idea, currently, what the reflection API does or how to implement the reflection API in my new server. The documentation for an extension should, I think, include the name(s) of the method(s) that must be implemented for a conforming implementation of that extension, and the signatures of those methods. This is not a run-time issue, it's a developer implementation issue, so specServices does not accomplish what I'm referring to.

Derrell


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rpc* backend "harmonization"

panyasan

Derrell Lipman wrote
On Sun, Nov 29, 2009 at 11:11, panyasan <info@bibliograph.org> wrote:

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

That's not what I'm talking about. The server writer needs to know how to
implement a conforming implementation of the extension. Without looking at
the PHP server, I'd have no idea, currently, what the reflection API does or
how to implement the reflection API in my new server. The documentation for
an extension should, I think, include the name(s) of the method(s) that must
be implemented for a conforming implementation of that extension, and the
signatures of those methods. This is not a run-time issue, it's a developer
implementation issue, so specServices does not accomplish what I'm referring
to.
Ah, ok, I see. Yes of course, I need to add information on that!

Cheers, C.
123