On Sat, Oct 18, 2008 at 5:46 AM, Thomas Broyer <[EMAIL PROTECTED]> wrote:
> I started playing a bit with an OOPHM client (for GWT-in-the-AIR). I > lloked a bit at the code and thought I could inherit BrowserChannel to > benefit from the *Message nested classes and the reactToMessages* > methods. > > First, I wanted to know what kind of messages were exchanged, so my > BrowserChannel impl (or, actually SessionHandler impl) just prints out > the received messages and eventually sends back a ReturnMessage with > "undefined" value (new Value()). > That's an approach that could very-well be used for unit-testing the > OOPHM server-side impl code (AFAIK, there's no test harness for > OophmBrowserChannel, OophmSessionHandler et al.). In a previous branch, there are Mock classes for the client and server, but they haven't been kept up to date. The problem is that for any sort of higher level test you need to implement a lot of things that the client/server code implements. I think once the wire protocol is completely settled it may make more sense to try and code up mocks for each side, but until then you are just making implementations of the same code in two different languages and duplicating effort. Running the full GWT test suite certainly covers all that code anyway. First thing to notice: it just doesn't work, for 3 reasons: > 1. LoadJsniMessage::receive() calls stream.readUTF() instead of > BrowserChannel::readUTF(); that's a very small bug and was easy to > fix. > 2. Much more of a "design mistake" (IMO) is that InvokeMessage is > asymmetric: InvokeMessage::send() sends a "method dispatch ID" while > InvokeMessage::receive() expects a "method name". This means > InvokeMessage (hence BrowserChannel) cannot be used as-is for client- > side OOPHM. The needs of each side are different, so it seems correct to use a different API. For example, we avoid ever sending the names to the client side at all (the injected JSNI has only dispatch IDs) which saves bytes in the wire protocol and the need for the client to keep track of them, including making round-trips to lookup the dispatch IDs. On the JS side, it has no such equivalent so we have to send the method names. However, I have no objection to splitting it into different message classes as you propose below. > 3. the reactToMessages* methods are server-side oriented (for > instance, they don't react to LoadJsni messages) > > So I started "patching" branches/oophm: > - split InvokeMessage into InvokeByDispatchIdMessage and > InvokeByNameMessage (could also have instead added a boolean to > InvokeMessage serialization to tell whether it's a by-dispatch-id or > by-name message) > - added an invoke() method to SessionHandler with a "method name" > argument instead of the "method dispatch ID" (implemented as a "throw > new UnsupportedOperationException()" in OophmSessionHandler) > - added a loadJsni method to SessionHandler > (UnsupportedOperationException in OophmSessionHandler) and added > LoadJsniMessage handling to reactToMessages* methods. > > These changes (maybe others are needed though) make BrowserChannel > usable both as a client and server, so you can write an OOPHM client > in Java. > > But maybe it'd be better to have a ServerBrowserChannel and > ClientBrowserChannel with distinct reactToMessages* implementations > (InvokeMessage would still have to be changed though, to accept > receive()ing a "by name" message and send()ing "by dispatch id" > messages). > Yes, I think you should have different session handlers for what the client and server would provide, which I believe also means splitting client/server BrowserChannel. > What do you guys think about it? (first the idea of using > BrowserChannel as the basis to implement an OOPHM client, and then the > proposed changes to BrowserChannel to make it possible) > I don't have any philosophical objection to it, though I think it is early to commit to multiple implementations and trying to keep them up to date. There are a number of changes we plan to make in this area before release (though perhaps not before it goes into trunk): - remove unused cruft in the protocol, such as InvokeSpecial - decide if we are going to support direct JS access to Java arrays or not, and if so implement them (probably with a new JS proxy object and perhaps a new Value type) - implement support for switching the main portion of the communication to an alternate channel, such as shared memory. But, if you want to do the work and provide the patch for branches/oophm to split BrowserChannel into client/server pieces with their own session handler, we can probably get it committed and keep it up to date. Since the Java client-side code would not get exercised much there would need to be some basic tests included, but it probably should not do more than testing individual messages since we wouldn't want to have to keep all that up to date as the client code changes. Does that sound reasonable? -- John A. Tamplin Software Engineer (GWT), Google --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
