Hi the list ! I'm pleased to announce we launched the rewrite of RPC Java.
We started using the RPC Java contrib few months ago now. As said at this time, we felt we'll have to rewrite it but I decided to wait until we really know well the API and concepts. We are currently writing a technical doc where a new design will be explained. We will submit it here as a starting point for a community discussion. We will try to add the new concept we are thinking about in addition the the current behavior. This will be a Java implementation of the RPC server spec we can find in the wiki so the following questions are only on the Java implementation "details". Also the first question I would have the the minimum JDK we'll have to handle. Should we take care of JDK older than Java 5 ? To use annotation, Java 5 is the minimum, so this would prevent older JDK to be used with that RPC Java 2.0 contrib. Another question to the community : one key concept for the serialization if the way to tell to the API the things to include and the things to exclude from serialization. Fortunately, there is a Java keyword for that : transient. I'd like to use it so if will respect the KISS design pattern (Keep It Simple, Stupid !) :-) Note : it will be possible to continue using the current behavior that rely on getter/setter rather than attributes even if I think it's a mistake. Currently, a Map of attributes/values if computed using Apache beanutils based on Java Bean concept : all get* methods are called the populate the Map. Then, in a post Map building step, we can remove/add lines. The attributes approach look better because only the non transient attributes are serialized, no need to call all the get* methods, while some of them are often not "true accessors". In that attributes approach it is also possible to amend the Map so dynamic modification are still possibles (transient tagging is hard coded). Anyway, we will explained all the details in the doc, this was explained only for you to have the context to answer the question : is transient the right way to tag attributes when the attributes way is choosen ? Good : it is already a Java keyword designed exactly for that purpose, mark attribute for no serialization. Bad : if a class is reused on another context, transient might not be true for a qx serialization ? I'm not sure this happen ... What do you think ? Other possible solution would be to use a specific annotation like @QxSerialize and/or @QxNoSerialize, that way, class could be reused in other contexts, only our specific annotation will be taken into account for that serialization. Performances will be taken into account in a second iteration. First make it works. Second make it quicker. Of course, the result will be submitted as an open source contribution. Comments are welcome ! ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
