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.

Reply via email to