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.
