On Sat, Oct 18, 2008 at 2:40 PM, John Tamplin wrote: > On Sat, Oct 18, 2008 at 5:46 AM, Thomas Broyer wrote: >> >> 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?
Attached is a patch against branches/[EMAIL PROTECTED] which:
- moves the BrowserChannel's reactToMessages* and invoke methods into
a ServerBrowserChannel subclass
- moves the SessionHandler methods into a ServerSessionHandler,
except for the freeValue method
- adds ClientBrowserChannel and ClientSessionHandler
- changes Message to no longer keep a reference to a BrowserChannel
but get one passed as an argument to the send() method, overloaded for
ClientBrowserChannel and ServerBrowserChannel (and delegating to a
single, protected doSend(BrowserChannel))
- changes Message subclasses to override the appropriate
send()/doSend() methods, and changes their receive() static method to
take an appropriate BrowserChannel-subclass instance as an argument,
if needed (for instance, InvokeMessage has different implementations
for receive(ServerBrowserChannel) and receive(ClientBrowserChannel),
and for send(ServerBrowserChannel) and send(ClientBrowserChannel))
- I've also replaced the "new *Message(...).send(this)" constructions
to "*Message.send(this, ...)" to avoid creating "temporary" instances
when possible.
As a result, I didn't need to change the wire protocol (hence the
plugins), because InvokeMessage's serialization/deserialization is
different depending on context (client vs. server). This not "ideal"
but has the added benefit that plugins don't have to be updated.
Note that the "sample" code I mentionned in my previous message is
still on my work laptop (I forgot to make a copy to continue things at
home this week-end; the changes I mentionned in my previous message
were also listed from memory, from home), so the attached patch hasn't
been tested at all!
(I'll rewrite my dummy client tomorrow or test the patch at work
monday, and update it if needed)
As for the "support for switching the main portion of the
communication to an alternate channel, such as shared memory", how
about adding BrowserChannel constructors such as:
public BrowserChannel(String name, InputStream is, OutputStream os) {
remoteEndpoint = name; // used by getRemoteEndpoint id socket==null
streamFromOtherSide = new DataInputStream(new BufferedInputStream(is));
streamToOtherSide = new DataOutputStream(new BufferedOutputStream(os));
}
so you could use PipedInputStream/PipedOutputStream for in-process
communication (memory shared between processes need some JNI or
third-party lib AFAIK, so you could probably map an
InputStream/OutputStream API on top of it; and of course add some
"negotiation" code into the plugins and GWTShell so that they use
shared memory if they run on the same machine and fallback to sockets
otherwise).
--
Thomas Broyer
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
clientside_oophm_r3776.patch
Description: Binary data
