+1 to Dave's suggestion to leave tabs out for now, at least until we have a non-tabbed implementation we can compare it to.
On 25 January 2011 02:15, David Hearnden <[email protected]> wrote: > 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 > >> > > > >> > > >> > > >
