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 > > > > > >
