Seems like your pattern is easily solved (I didn't look at your compiler
suggestion, so this isn't a comment about that).  Have your clients send a
timestamp in the RPC to the server.

The server then takes the highest timestamp & tells the client that it
doesn't need to listen to notifications & instead listen to some other
module.

Then for your central communication, you can use JSNI to transfer data
between modules, or, better yet, have 1 module that inherits the other
modules & can then provide them with a ServerEventsRouter to use.

On Wed, Apr 8, 2009 at 6:04 AM, Yann <jan.vorw...@googlemail.com> wrote:

>
> ===============
> Context information
> ===============
>
> In order to handle server "push" events, I am using a pattern
> described and used in multiple places: a getEvents() RPC method waits
> for up to 30 seconds but returns as soon as an event is received.
>
> The issue is that this pattern eats a browser connection, so that if
> two GWT modules (loaded on a given page) do register to server events,
> the 2 allowed connections are wasted.
>
> Hence my desire to have a central events receiver/router in the
> browser and possibly several GWT modules listening to that router.
>
> ===============
> In the router:
> ===============
> public class ServerEventsRouter
> {
> ....
>    public static void addServerEventsListener( ServerEventListener
> listener )
>    {
>        // register the listener in a collection...
>    }
> ...
>
>   private static native void createRegisteringFunction() /*-{
>        $wnd.addServerEventsListener =
> @com.foo.gwt.ServerEventsRouter::addServerEventsListener(Lcom/foo/gwt/
> events/ServerEventListener;);
>    }-*/;
>
> ...
>
> }
>
> The createRegisteringFunction() needs to be called first somehow...
>
> =======================
> And then, in the client listener:
> =======================
>
>    private native void registerServerEventsListener
> ( ServerEventListener listener )/*-{
>        $wnd.addServerEventsListener ( listener );
>    }-*/;
>
> and
>
>   registerServerEventsListener( new ServerEventListener() {
>       public void onServerEvent( ServerEvent event ) {
>           GWT.log( "Received event", null );
>       });
>
>
> ===============
> The Issue(s)
> ===============
> However, as you might expect, this doesn't work. Well, it works for
> 'hello world' type of functions which not not require parameters...
> but the ServerEventListener parameter is not "marshalled" properly.
>
>
> A. In WEB mode
>
> The ServerEventListener interface is not implemented by any class in
> the router module, so that the dispatching function is optimized from:
>
>    for ( ServerEvent event : events ) {
>        for ( ServerEventListener listener : listeners ) {
>            listener.onServerEvent( event );
>        }
>    }
>
>    into something like:
>
>    for (event$iterator = events.iterator(); event$iterator.hasNext
> ();) {
>        dynamicCast(event$iterator.next_0(), 11);
>        for (listener$iterator = $AbstractList$IteratorImpl(new
> AbstractList$IteratorImpl(), this$static.m_listeners); listener
> $iterator.i < listener$iterator.this$0.size_0();) {
>            throwClassCastExceptionUnlessNull($next_1(listener
> $iterator));
>            null.nullMethod();
>        }
>    }
>
>
> B. In HOSTED mode
>
> Presumably in order to match the behaviour of the WEB mode, the
> classes in the two modules are loaded from two different class
> loaders, so that the implementations of the ServerEventListener are
> not seen as such in the router module and any assignment generates a
> class cast exception.
>
>
> ===============
> My proposal
> ===============
>
> Instruct the compiler not to optimize out sub-classes of a specified
> type (here ServerEventListener), and have these classes loaded from a
> common upstream (i.e. "more global") class loader in Hosted Mode.
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to