Hi Jarnis. Since this didn't generate a response, I'll share some thoughts. First a disclaimer: I haven't used Wicket-Atmosphere yet, but I've read what there is to read and am looking forward to it. (We have several use cases that will benefit greatly.)
Are there any good arguments for not just using Atmosphere events throughout > the application, completely avoiding Wicket and Guava events? Are these events changing the DOM in ways Wicket should know about? It seems like most non-trivial event content would require corresponding changes to your Wicket component graph, e.g. preparing for clicks. But if you have a container that doesn't need to interact with Wicket, and you don't mind writing the client- and server-side plumbing directly, maybe it makes sense. > Are there significants advantages (for instance performance related) to > using wicket > native events for the component-component messaging? Wicket's built-in events work well within the Wicket architecture. If a random event comes in on a Guava bus, you have to ask yourself, "okay now how do I get access to this or that component that's serialized in the page store?" Wicket events have well-defined access to the important objects (Application, Session, RequestCycle, Page, Components), and a simple way to target only a subset of those. I don't think server-side performance should be your concern here. Unless you have a super crazy component count Wicket events are plenty fast. Hope that helps. Dan
