Community
Participate
Working Groups
On RAP we need to keep the server and client in a consistent state. RAP already reached this consistent state with a fast and reliable solution. But the solution has one drawback. It couples the client and the server to each other. Currently the server sends JavaScript to the client. This JavaScript will be evaluated on the client side. With a protocol we need no JavaScript within a message. Therefore no evaluation is needed to bring the client in a consistent state. This makes the debugging of messages much easier. Another benefit of the protocol is that we don?t need to generate valid script code on the server side anymore. With eliminating the described coupling we will make RAP open for new client technologies.
I opened two CQs for this bug. The CQs are: - 4052 A PB to the Java Version of the JSON.org parser - 4053 the JavaScript Version of the JSON.org parser
Hello Holger, I went through the process about 2 months ago to check-in the approved org.json codebase as an orbit bundle to help support the Google visualization widgets in the incubator. Does the version that has been approved work for your purposes? One of the drawbacks I found to this version was the lack of java.util.Date specific processing. I had to position several workarounds to enable the visualizations to depend on the orbit bundle as is.
I saw a state change on this bug, and it reminded me that I wanted to make a couple of comments about it. First, I think the title of the bug is unclear...what does 'well-defined' mean? I think a more appropriate and ambitious goal would be to install a 'standard' protocol...or even introduce 'protocol independence' for RAP. Both of these would be far more effective as a way to introduce what I think this bug really wants to get at: a clear and formal separation between the on-the-wire client-server protocol for RAP, and the semantics of the inter-process communication required by RAP. Second, I would suggest making clear that a with java (and other object-oriented languages) a 'protocol' really has two aspects: a) the actual on-the-wire protocol and b) the object serialization/deserialization format (for marshalling/unmarshalling). To create a real separation between system layers...in the OSI ref model sense...and pluggability/independence of lower layers...this means having to have pluggability with *both* of these aspects. From the beginning, ECF's general approach has been to define explicit APIs (e.g. remote services/distribution, discovery as well as file transfer, presence, etc), that say *nothing* about either the wire protocol or the serialization format. Each provider/actual comm impl defines those things. Existing providers can/are based upon standardized protocols (like XMPP), and common/standardized serialization formats (like json...which is included with ECF 3.3). This allows clients/servers that use/implement these APIs to modularly replace either on-the-wire and/or serialization formats as needed (even at runtime)...with private/proprietary wire protocols (or serialization formats), or with open/common standardized ones. This is what I think this bug is trying to actually achieve for RAP...as having a compile-time binding to a single wire protocol and/or serialization format ultimately creates headaches...as I think the RAP team has (re)-discovered.
(In reply to comment #3) Thanks Scott for your input. I agree that the title is a bit unclear. Instead of 'well-defined' it should read 'formalized'. I changed the title accordingly. The idea to is to specify a communication format between client and server instead of sending JavaScript commands directly. Holger already worked on a JSON based format and implementation, that is tailored to the RAP use case. With this change we'll get what you suggest: > a clear and formal separation between the on-the-wire > client-server protocol for RAP, and the semantics of the inter-process > communication required by RAP. Regarding protocol independence: With the new data format we can easily exchange the protocol below, since we will not use HTTP specifics anymore like putting information into HTTP parameter names. However, RAP is a web-framework that cannot live outside of a browser. I currently see no use for an exchangeable protocol and think that without a use case this would be a *needless* abstraction.
(In reply to comment #4) > (In reply to comment #3) > Thanks Scott for your input. I agree that the title is a bit unclear. Instead > of 'well-defined' it should read 'formalized'. I changed the title accordingly. > The idea to is to specify a communication format between client and server > instead of sending JavaScript commands directly. Holger already worked on a > JSON based format and implementation, that is tailored to the RAP use case. > With this change we'll get what you suggest: > > > a clear and formal separation between the on-the-wire > > client-server protocol for RAP, and the semantics of the inter-process > > communication required by RAP. > > Regarding protocol independence: With the new data format we can easily > exchange the protocol below, since we will not use HTTP specifics anymore like > putting information into HTTP parameter names. However, RAP is a web-framework > that cannot live outside of a browser. I currently see no use for an > exchangeable protocol and think that without a use case this would be a > *needless* abstraction. I think this is a short-sighted view. For example: I expect that two years ago a 'rap protocol' would have been considered a needless abstraction. Now it's not. What changed?
(In reply to comment #5) > I think this is a short-sighted view. For example: I expect that two years > ago a 'rap protocol' would have been considered a needless abstraction. Now > it's not. What changed? Call it short-sighted. We call it "design for the moment". Avoiding speculative coding is a good agile practice and part of the way the RAP team decided to stick to. See http://c2.com/xp/YouArentGonnaNeedIt.html If we would have build in all those abstractions from the beginning, RAP would not be where it is today.
(In reply to comment #6) > (In reply to comment #5) > > I think this is a short-sighted view. For example: I expect that two years > > ago a 'rap protocol' would have been considered a needless abstraction. Now > > it's not. What changed? > > Call it short-sighted. Ok, I will (and did). That's because it is. >We call it "design for the moment". That's convenient...and shortsighted. >Avoiding speculative > coding is a good agile practice and part of the way the RAP team decided to > stick to. See http://c2.com/xp/YouArentGonnaNeedIt.html Thanks anyway...I know Ward personally, and so am already familiar with this. Thing is, taken to the extreme (which is what you are apparently and conveniently doing)...without taking into account other important maxims of design (like 'don't reinvent the wheel', 'learn from what others are doing', 'software is about abstraction', and 'don't do work that others have already done', this approach leads to long-term failure and irrelevance...and I would say that RAP is well on the way down that path. > > If we would have build in all those abstractions from the beginning, RAP would > not be where it is today. Ok. You can obviously have it your way. The world does have GWT after all (as well as others).
Hi Scott, thanks for your tipps, tricks and your opinion. It seems that you'r really interested in preventing us from making failures with RAP. So, the good thing about RAP and ECF is that they are open source. I would really like to see an implementation of such a consistency protocol in RAP based on ECF. But the thing is nobody in the RAP team can do it. So, I would really appreciate it if you can make a prototype of your suggestion. When we have such an implementation we could evaluate it for all the RAP use cases and see if we can use it. We are all open for questions that goes into detail which surely come up when implementing a protocol for the consistency purpose in RAP. Thanks in advance. Regards Holger
(In reply to comment #8) > Hi Scott, > thanks for your tipps, tricks and your opinion. It seems that you'r really > interested in preventing us from making failures with RAP. So, the good thing > about RAP and ECF is that they are open source. I would really like to see an > implementation of such a consistency protocol in RAP based on ECF. But the > thing is nobody in the RAP team can do it. So, I would really appreciate it if > you can make a prototype of your suggestion. I can't commit to doing this for you...although the relevant mechanism is all in place already in ECF 3.3/Helios. For example, Holger S started the work on the REST-based remote service provider in summer 2009, and with my and others work on it over the past year, it is now mature. See http://wiki.eclipse.org/REST_abstraction_for_ECF and some other useful links: http://eclipseecf.blogspot.com/2010/02/osgi-remote-services-and-sync-vs-async.html http://wiki.eclipse.org/ECF#OSGi_4.2_Remote_Services Given Holger S's involvement in the REST provider (and the fact that he is an ECF committer) I suspect that he can/could do it...or others could learn/use the necessary APIs with only casual effort at learning. >When we have such an > implementation we could evaluate it for all the RAP use cases and see if we can > use it. We are all open for questions that goes into detail which surely come > up when implementing a protocol for the consistency purpose in RAP. Sorry, no. I do not have the resources to do this gratis specifically for the RAP team. You/RAP team are free, of course, to use (and enhance/contribute to if that's your desire) ECF's existing work as described above.
Here's a question for you Holger: What is meant by 'formalized' in this bug title? Are you referring to wire protocol? Marshalling/serialization format? Both? Something more/else?
As of RAP 2.0, the open JSON Protocol [1] is used for all communication between client and server. [1] http://wiki.eclipse.org/RAP/Protocol
