Hi Jean, Thanks for response, I'm definitely interested about your json-rpc implementation!
Can you send me some link where I can download it? I'd like to study it before I will try to use it. Thanks -- Best regards - Petr Kobalicek <http://kobalicek.com> On Tue, Jan 19, 2010 at 9:16 AM, Jean-Baptiste BRIAUD -- Novlog <[email protected]> wrote: > > On Jan 18, 2010, at 20:50 , Petr Kobalíček wrote: > >> Hi Jean, >> > Hi Petr, > >> Is it possible to specify some schema and serialize / deserialize data >> based on this schema? >> > What are you calling "a schema" ? There are no "schema" in Java ... > We are serialize/deserialize classes. Nothing special in that classes. > Nothing to implement, really nothing that should make that class different > because of serialization. > Only transient standard java keyword is used to mark attribute you statically > don't want to serialize/deserialize. > >> I'm currently developing own json-rpc implementation, because there is >> no json-lib that allows this. I based code on the older rpc (author >> granted to use apache licence for final product), but it's hell for me >> (I'm far from the completion). My needs are probably different than >> others so transient keyword is not enough for me - I need to serialize >> different keys in different contexts/controllers, for example if I >> want only list of some objects, I want to serialize only few members, >> but if I want to edit/save object, I want to serialize nearly all >> members, how this is solved in your code or in other libs? > > That's exactly what we are doing ! > That's what I try to explain by using static and dynamic way to > include/exclude attribute. > Static way is the use of transient keyword. A transient will never ever been > serialized or serialized. > You exclude that attribute "by construction" in the class, at compile-time. > Dynamic way is a way to include/exclude attribute depending on something that > can change at run-time. > > We coupled that with OpenJPA FetchPlan, I can tell you, it is an "atomic > design", it simply annihilate some problem :-) > and it is very efficient : only useful data use the network bandwidth. No > waste. > > Say you have a Customer class : > public class Customer { > protected String name; > protected transient int specialCRC; > potected String address; > } > > That specialCRC could be siomething you compute only on server side and you > don't want on client side. > Satically at compile-time, you exclude for ever that attribute that won't be > used on client side : transient. > > Then, depending on the business usecase, you cant the Customer's instance > with both name and address, or only with name, ... > That is choosen dynamically. > That dynamic (run-time) choice can have short or long live. > Long live is the live of the serializer. So you can exclude "nearly for ever" > without having to touch the Customer's class source file. > Short live is the live of a call, the one that we are using with FetchPlan. > > Hope this helps ! > > >> >> Thanks >> >> -- >> Best regards >> - Petr Kobalicek <http://kobalicek.com> >> >> >> On Mon, Jan 18, 2010 at 10:21 AM, Jean-Baptiste BRIAUD -- Novlog >> <[email protected]> wrote: >>> Hi, >>> >>> Few words on our new Java-RPC implementation : >>> >>> We are in the process of delivering a qooxdoo contrib for a new Java-RPC. >>> The contrib name is not set. >>> Should it be "Java RPC 2" ? >>> >>> >>> * Allow extra params to be added or removed on the servlet (or a filter), >>> before reaching the Controller. >>> You could manage the login/password at a generic level, so even if you pass >>> that 2 params on client side, >>> that 2 params won't be seen in the Controller. >>> This 2 params could be consumed in your authentication servlet. >>> >>> * Param could also be pass to the controller without having beeing passed >>> by client side. >>> This allow us to pass a transaction manager from OpenJPA to all method of >>> all Controller. >>> >>> * 2 times quicker than current implem on our very first small tests. >>> >>> * based on attributes introspection rather than getter/setter : won't call >>> anymore *all* getter for serialization. >>> All non transient attributes will be serialized. >>> >>> * Very "eco-java-friendly" (c) : nothing is added unless it is really >>> needed : >>> - use Java transient keyword, no extra annotation needed >>> - use default included in the JDK RMI exception for the controller. >>> No extra exception or interface added. >>> >>> Use java.rmi.Remote interface (an empty interface) that Controller must >>> implement. >>> Use java.rmi.RemoteException as the exception to be thrown by remote method. >>> In case it is thrown, this will be seen as an error on client side. >>> >>> * Compatible with current implem on client side point of view. No qooxdoo >>> code will need to be change. >>> Our implementation pass Derell client side test code. >>> On the server side, Controller code from current implem will need small >>> refactoring (RemoteException and the Remote interface). >>> Business object from current code will need deeper refactoring since all >>> getter/setter added only for the shake of serialization can be removed. >>> You may have to add transient modificator to some attributes you don't want >>> to serialize. >>> >>> * On a design point of view, we are also using internally, json.org >>> implementation, slightly modify for the date. >>> We have designed 2 separate library (can be package separately) one for >>> serialization and one for remote call. >>> >>> * Important design point : serialization is done in 2 steps : java object >>> -> Map of attribute's name/ value -> JSON >>> and back from JSON -> Map of attribute's name/ value -> java object. >>> This is done so one can modify standard behavior at the map step. >>> That step allow you to add/remove/rename/change value of any attributes >>> before JSON or before java object. >>> There are also 2 ways of doing that : each call (fully dynamically, like it >>> depends on some criteria, any attribute value, wind direction, ...) >>> or for the life of the serializer (like rules that would be always true for >>> your application). >>> >>> >>> PS : I assumed Controller is a known concept, but feel free to ask question. >>> >>> Hope this will help. >>> ------------------------------------------------------------------------------ >>> Throughout its 18-year history, RSA Conference consistently attracts the >>> world's best and brightest in the field, creating opportunities for >>> Conference >>> attendees to learn about information security's most important issues >>> through >>> interactions with peers, luminaries and emerging and established companies. >>> http://p.sf.net/sfu/rsaconf-dev2dev >>> _______________________________________________ >>> qooxdoo-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> >> ------------------------------------------------------------------------------ >> Throughout its 18-year history, RSA Conference consistently attracts the >> world's best and brightest in the field, creating opportunities for >> Conference >> attendees to learn about information security's most important issues through >> interactions with peers, luminaries and emerging and established companies. >> http://p.sf.net/sfu/rsaconf-dev2dev >> _______________________________________________ >> qooxdoo-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
