On Tue, Nov 23, 2010 at 4:27 PM, Michael MacFadden < [email protected]> wrote:
> And yes, I saw the mock ups that got checked in. I started digging to > see how I would figure out how many blips were there and what was read > and non read. I traced the code and started debugging. That is when > I ran in to this issue. > > As a side comment, I couldn't tell from the mock ups if the number in > toggle shows how many total sub blips, or the number of unread ones. > I assume the total number of blips in the inline thread. Thanks. > The current implementation we took is that when there are unread blips in the sub tree from the inline reply, the number represents the number of unread blips in the sub tree. When everything is read in the subtree, the number is the total count of blips in the sub tree. Having said that I've personally always found that confusing. I would have much preferred to always show the total number of blips always and maybe in parenthesis the number of unread blips if any. What's your opinion on this? Kind Regards > > ~Michael > > On Nov 22, 9:22 pm, Michael MacFadden <[email protected]> > wrote: > > I actually switched the code back: > > > > What was this: > > > > // Either use fake backing, or create UDW. The latter is racy, but > > usually what we want. > > // TODO: restore lines below, after issue 154 has been fixed. See: > > //http://code.google.com/p/wave-protocol/issues/detail?id=154 > > // udw = getWave().createUserData(); > > // supplement = WaveletBasedSupplement.create(udw); > > // supplement = new PrimitiveSupplementImpl(); > > > > is now this in my local: > > > > // Either use fake backing, or create UDW. The latter is racy, but > > usually what we want. > > // TODO: restore lines below, after issue 154 has been fixed. See: > > //http://code.google.com/p/wave-protocol/issues/detail?id=154 > > udw = getWave().createUserData(); > > supplement = WaveletBasedSupplement.create(udw); > > // supplement = new PrimitiveSupplementImpl(); > > > > I remember the other bugs related to issue 154. Those don't seem to > > be an issue when I switch back to the wavelet base supplement. > > However, the operations on the wavelet (through the supplement) don't > > seem to get synced down to the server. > > > > ~Michael > > > > On Nov 22, 4:24 pm, David Hearnden <[email protected]> wrote: > > > > > > > > > > > > > > > > > You're not barking up the wrong tree :) What's happening is as > follows. > > > > > On any wave you open, a wavelet with just you as a participant gets > > > created to track your user data (UDW). There was a period of > > > indecision about whether the client or the server should create this > > > wavelet (Google Wave does both, but there are unresolved race > > > conditions). In Wave-in-a-box, we decided to go with client-created > > > UDWs, but have not wired them up completely. The data structure that > > > the UDW provides is exposed as an interface called > > > PrimitiveSupplement. There is also a pojo implementation of that > > > structure (PrimitiveSupplementImpl). > > > > > You jumped straight to the right place in the code. That logic there > is saying: > > > 1. If a UDW already exists (getWave().getUserData() != null), then > > > build the supplement structure on it, exposing it as a > > > PrimitiveSupplement. > > > 2a. If a UDW does not exist, create one now, and then do 1. > > > 2b. If a UDW does not exist, create a fake in-memory version of the > > > data (PrimitiveSupplementImpl) and carry on. > > > > > 2a is what it should be, 2b is what it is currently. Last time we > > > used 2a it exposed some other bugs in the client/server protocol. > > > Those are fixed, so today I'll try again to switch from 2b to 2a so > > > UDWs are used properly. > > > The in-memory data structure is thrown away when you close a wave, so > > > read/unread state currently exists while you have a wave open, but if > > > you re-open that wave, even within the same client session, a new > > > PrimitiveSupplementImpl is created. That explains the behaviour > > > you're seeing regarding persistence of user state. > > > > > What is surprising though is that createUserData() is getting called. > > > If that is occurring, then the UDW should be working, and > > > getWave().getUserData() should be non-null. I'll investigate today. > > > > > In the meantime, did you see the blip counter HTML mocks I checked in? > > > > > -Dave > > > > > On Tue, Nov 23, 2010 at 10:07 AM, Michael MacFadden > > > > > <[email protected]> wrote: > > > > All, > > > > > > I am looking into implementing the inline thread toggle which shows > > > > how many blips are in the inline thread as well as an indication to > > > > how many are read / not. > > > > > > To do this I believe we need working User Data Wavelets. I was > taking > > > > a look at where these are created when creating a new wave. Looks > > > > like this is happening in the StageTwo class here (circa line 390): > > > > > > === > > > > > > protected ObservableSupplementedWave createSupplement() { > > > > Wavelet udw = getWave().getUserData(); > > > > ObservablePrimitiveSupplement supplement; > > > > if (udw != null) { > > > > supplement = WaveletBasedSupplement.create(udw); > > > > } else { > > > > // Either use fake backing, or create UDW. The latter is > > > > racy, but usually what we want. > > > > // TODO: restore lines below, after issue 154 has been fixed. > > > > See: > > > > //http://code.google.com/p/wave-protocol/issues/detail?id=154 > > > > udw = getWave().createUserData(); > > > > supplement = WaveletBasedSupplement.create(udw); > > > > // supplement = new PrimitiveSupplementImpl(); > > > > > > } > > > > return new LiveSupplementedWaveImpl( > > > > supplement, getWave(), getSignedInUser(), > > > > DefaultFollow.ALWAYS, getConversations()); > > > > } > > > > > > === > > > > > > This line specifically "Wavelet udw = getWave().getUserData()" always > > > > comes back null. This code seems to get executed when a wave is > > > > loaded in to the client. It seems that: > > > > > > getWave().createUserData(); > > > > > > does get called and execute after clicking the "New Wave" button. If > > > > you debug you will see that the wave now has a new wavelet for the > > > > user data. But immediately after if you click on the wave again, the > > > > getWave().getUserData() will return null. The wave no longer > contains > > > > the wavelet for the user data. Is the creation of the user data > > > > wavelet only happening on the client side and not getting persisted > to > > > > there server? > > > > > > I think I need to get this working first, if I am barking up the > wrong > > > > tree let me know. > > > > > > Regards, > > > > ~Michael > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- David Wang -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
