The wave-based search has many advantages over simple RPCs (allows the server to push data to the client, efficient incremental updates, ...), but I also agree that getting something working simply and quickly end-to-end is very important. I think it would be wise to build the various components in a way where the search model is agnostic about its underlying transport, so it can start off as an rpc-based model, but can be upgraded later to the wave-based one without having to rewrite the search package all over again. That should be easy with some thoughtful APIs.
For the RPC protocol, there are some key questions to address early. Is the response streaming? Are the updates incremental? Going for simplicity, I'd recommend no streaming and no updates: keep each search request is independent, and each response is a complete collection of results, not an update to merge with previous results. The client can poll every 30s as you suggest. That's probably what you had in mind anyway, but it would be good to clarify. That simplicity is there to get something functional quickly without investing too much engineering effort. If there is spare effort to spend, I think it would be more wisely invested in the wave-based approach. On a lower level, you can define the RPC signature using protos then use PST to generate the GWT-friendly message classes. Let me know if you want more info on that. For the Client / Search-UI interaction, please avoid using the event bus model, since it spaghettifies control flow, avoids responsibility, and makes things impossible to test and debug. So rather than having WaveListPanel fire a search event out into the vacuum, hoping that WebClient picks it up, it would be better to have explicit interfaces between the search component and WebClient. Ditto for the control flow of search results. In fact, I'd recommend minimizing the interaction with WebClient, and have the search component largely look after itself, rather than hook into WebClient. I'd highly recommend using MVP for building such a UI component. That search component can have its own data model, backed by a search service, its own UI (which you've already done), and its own presenter for pushing/pulling data between the model and the UI. The search tabs sound quite useful, but I wouldn't invest much time in it upfront. Perhaps wait until a single tab is up and running first? Finally, it's valuable to think from the outset about how to build the search component in a way where its startup latency can be optimized later. On Webkit it's currently tolerable, because the websocket connects quickly, and the GWT app startup latency is bearable, and if the server is nearby then the inbox request comes back quickly, so there's only 1-2s after logging in before you see your waves. On Firefox/IE, the startup latency is well into the 4~5sec mark, and that's permanent: none of the significant contributors to the latency of that startup flow can be improved (JS download/parse/execute, RPC RTT, etc). There are two strategies we adopted in Google Wave to address startup latency. First, we optimistically performed the inbox search on the server, and injected the results onto the initial page as JSON. This means that the client doesn't do any RPCs to get the initial inbox state, so doesn't need to wait for sockets, so all that's left is the GWT app startup time. Try and can keep the code open to that optimization, because it will make a huge difference on Firefox. The second strategy is server-side rendering, so that you see data on the page immediately, without having to wait for JS to download/parse/execute. We didn't get that done for the search panel, but we did for the wave panel. Server-side rendering is really the only solution to making an app not feel slow, and directly conflcts with GWT's Widget architecture. So the fewer GWT widgets you use (use plain HTML instead), the easier it becomes to speed up the loading of UI component. I'm not suggesting making the search panel server-side renderable right now, because it does involve a little bit of extra effort, but not preventing it as a future optimization would be useful (of course, if you want it to be server-side renderable right now, then that would be fantastic, and I can tell you all about how the wave panel is built to support it, and how the search panel could be built in a similar way). The key part in keeping it open as a future optimization, without having to rewrite the whole search component again, is to keep the view and the presentation logic separate (MVP), and to keep the presentation logic free from dependencies on Widgets, and use View interfaces instead. But yes, in summary, your plan sounds good to me. -Dave On Tue, Jan 25, 2011 at 9:32 AM, Yuri Z <[email protected]> wrote: > Thanks for the info. > If I understand it correctly - then the Data API + RPC is the easiest > approach - even if the most limited. I prefer to advance as fast as possible > to something working and then to improve based on the info provided above. > So, here how I plan to implement it: > User inputs query and hits enter > Search event fired from WaveListPanel and handled by the event handler in > WebClient. > WebClient uses helper class similar to SnapshotFetcher to make a call to > the server. > The search helper servlet (similar to FetcherServlet) receives the request > and makes use of SearchService to execute the query and then returns the > result to client. > WebClient fires SearchResultUpate event and the WaveListPanel handles the > event with search results. > The WaveListPanel would be modified to display up to 5(?) digests lists > (instead just the inbox one), each in its own tab. > The additional tabs with search results will be refreshed every 30(?) > seconds, user can dismiss a tab (inbox tab cannot be dismissed) . > > I will be glad to hear comments if it is something feasible/good enough. > Thanks > > > 2011/1/24 David Hearnden <[email protected]> > > Just an FYI: there is a load of legacy code in the web client that remains >> solely to keep running the inbox protocol (i.e., there are two separate >> code >> stacks for running and rendering waves: the new one, which is used for all >> waves except the inbox wave, and the old one which is used just for the >> index wave). I'm very keen to see a clean search protocol happen, so it >> can >> be implemented on the new wave stack, and then we can chuck out a good >> deal >> of prototype-level code. >> >> Another piece of info: In Google Wave, the RPC-based search results has >> some non-trivial complexity. I think there are three layers of results, >> each filtering or modifying the results of the layer below: the raw >> results >> from the server, some other layer for some other reason in the middle, and >> then a top layer that includes client-side optimism (e.g., if you archive >> a >> wave it gets removed from your inbox locally on the client immediately, >> rather than waiting for the server to remove it over the streaming RPC). >> As >> well as optimistic search, there is optimistic digesting. Whenever you >> open >> a wave that is in your search results, the data source for the "digest" >> (i.e., the data model that represents everything you see in each entry: >> some >> participants, title, snippets, read/unread count, LMT, etc) switches to be >> sourced directly from the wave itself, rather than the digest in the >> search >> result, so that as you add/remove blips, read blips, edit the title etc, >> you >> see the digest of that wave update instantaneously, rather than waiting >> for >> a server search update to come through. I can publish most, if not all, >> of >> that code if you're interested, although it might not be useful until the >> underlying protocol is functional. >> >> -Dave >> >> On Mon, Jan 24, 2011 at 12:08 PM, Alex North <[email protected]> wrote: >> >> > In Google Wave search is implemented as an RPC, with streaming results >> so >> > that the results can change live. >> > >> > There is support for using a wave for search result transport in WIAB. >> > Joseph and I made this design last year: >> > >> > >> http://www.waveprotocol.org/protocol/design-proposals/search-wave-design-proposal >> > >> > On 22 January 2011 06:51, Yuri Z <[email protected]> wrote: >> > >> > > Hi >> > > I am looking into implementing the client side of search >> functionality. >> > If >> > > I >> > > understand it correctly - this would require modifications to wave >> index >> > > update mechanism. In any way, if it's possible I would like to know >> how >> > it >> > > was implemented in Google Wave or maybe was intended to be implemented >> in >> > > Wiab before I try to come up with my own solution. >> > > Thanks >> > > >> > >> >
