incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Review Request: Fix for WAVE-374 and "New wave" responsiveness
Date Sat, 27 Oct 2012 15:22:40 GMT

This is an automatically generated e-mail. To reply, visit:

Review request for wave.


This patch depends on and needs slight modification to
work properly together with

This is a draft of a patch that makes the digest list update faster with a new digest/inbox
item in the search/digest list when the user creates a new wave. This is done by adding a
temporary local digest that listens to wavelet updates until the real digest comes in from
a search result. Then the the temporary digest gets removed and replaced by the real one.

It also fix "WAVE-374: Browser 'backwards' button doesn't update wave list" by selecting waves
when they are about to be opened. This also results in the digest properly being selected
after a browser "refresh".

I need some input/feedback on the following questions:

1. Since the temporary local digest stays until the real digest is returned to the client
from a search result it will not disappear if the user have an active search that never finds
the new wave. Currently any other search than inbox or "all" would result in only showing
the temporary digest. The temporary digest would however disappear as soon as the user searches
for inbox or "all" again. Would this be an OK limitation for now or should it be solved somehow:
   - For example by not creating a temporary digest if the search is not inbox or "all"
   - Include the newly created wave in the searches that is being sent with 15 sec interval
so that the search can report when the new digest is properly created on the server-side
   - Listen for the server-side creation message in the newly created wavelet/digest itself.
   - Any other suggestion?
   - How did Google Wave work when you created a new wave that was not visible in your current
search? (not that we need to copy google wave but it could be a possible solution)
2. The same problem arises if the user creates a new wave and then quickly change the current
search from "all" or inbox to something else.
   - Could be solved by some of the above suggestions.
   - It could also be solved by removing the temporary digest if the search result gets changed
from "all" or inbox.

While this is mostly a fix that is needed now when we don't have live search I think it is
something that we would want even when live search is in place. It will always take some time
for the newly created wave to get properly created on the server side, so you always want
some temporary digest to appear fast.

Any feedback and opinions are welcome.


This addresses bug WAVE-374.


  src/org/waveprotocol/box/webclient/client/ b668d32 
  src/org/waveprotocol/box/webclient/client/ 863ae6c 
  src/org/waveprotocol/box/webclient/client/ 2eeec81 
  src/org/waveprotocol/box/webclient/search/ 152c142 
  src/org/waveprotocol/box/webclient/search/ b136c88 
  src/org/waveprotocol/box/webclient/search/ 5b018d4 
  src/org/waveprotocol/box/webclient/search/ 2111f64 



Tested on a local server but could use some more test when we've decided what to do with the
above questions



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message