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. ~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]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
