Dave,
Yes, the clients follow this step. I think I tried to follow your
suggestion, but still am not able to retrieve values from the map.
The call to create the map happens in one place:
public AnnotationWaveStore(Conversation root, WaveId waveId) {
this.doc= (ObservableDocument) root.getDataDocument(WAVE_ANNOT);
this.map =
DocumentBasedBasicMap.create(DefaultDocumentEventRouter.create(this.doc),
this.doc.getDocumentElement(), Serializer.STRING,
Serializer.STRING, ENTRY_TAG,
KEY_ATTR, VALUE_ATTR);}
and the same structure object will be called to store a value
public void addAnnotationToStore( String key, String annotation){
if (this.map != null)
this.map.put(key, annotation);}
which seems almost identical to your example, though perhaps different
enough to be problematic.
I wonder if getting the document from Conversation would mean that I
would run into the race conditions that you mention.
Or perhaps there's something else...
Thanks again
On Jan 3, 6:34 pm, David Hearnden <[email protected]> wrote:
> Does every client go through the same steps:
> 1. Get data doc
> 2. Create new top-level element ("child")
> 3. Read/Write attributes of "child"
> ?
>
> If so, then different clients would be reading/writing attributes of
> different elements in the data document. Trying to get different
> clients to agree on a common top-level element in which to embed data
> has race conditions that are difficult to resolve. Your best bet is
> not to try and use XML-like documents directly, precisely because of
> issues like this, and hundreds of others. What we ended up doing for
> other data documents (like the conversation manifest, user-data
> documents, etc) was to expose the document as a simpler type, like a
> map or a list, with code like:
>
> void init(Wavelet w) {
> ObservableDocument dataDoc = w.getDocument(...);
> SimpleMap<String,String> dataMap =
> asMap(DefaultDocEventRouter.create(dataDoc));
>
> // Now interact with the data doc using a plain map interface.
> dataMap.put("myKey", "myValue");
> String other = dataMap.get("otherKey");
> ...
> }
>
> static SimpleMap<String, String> asMap(DocumentEventRouter<? super
> E, E, ?> doc) {
> return DocumentBasedSimpleMap.create(router,
> doc.getDocumentElement(), Serializer.STRING, Serializer.STRING, "foo",
> "bar", "baz");
> }
>
> I'd recommend following that same strategy. At best, it will also
> address the race conditions I mentioned earlier, which may or may not
> occur in your scenario. At worst, it is less code for you to type: 1
> expression to turn a wave document into something exposing a simpler
> API. I'm not sure what data type best models the user data you need
> for your app (simple map, simple list, complex list, simple tuples,
> etc), but there are a range of such types in the wave libraries.
>
> -Dave
>
> On Jan 1, 2:18 am, cearl <[email protected]> wrote:
>
>
>
>
>
>
>
> > Thanks Alex,
> > If I understand correctly, I can just diff my version of critical
> > files ( I think there are two within the repository and one that I
> > have added ), place those in the codereview.waveprotocol.org
> > repository, and then post the relevant links?
> > C
>
> > On Dec 30, 12:08 am, Alex North <[email protected]> wrote:
>
> > > What you've described sounds approximately correct, though there are many
> > > details it's possible to get wrong.
>
> > > Can you export a patch somewhere we can take a look? On
> > > codereview.waveprotocol.org would be a good place (even though you might
> > > not
> > > be expecting to submit it to wave).
>
> > > A.
>
> > > On 30 December 2010 05:57, cearl <[email protected]> wrote:
>
> > > > Hi,
> > > > I've been trying to use data documents to store additional data
> > > > associated with a conversation. I'm hoping that someone can shed light
> > > > on the update mechanics that I need to take care of. I can't seem to
> > > > get my simple model to work for multiple users of the same wave.
> > > > Here's my model.
> > > > I'm using the WIAB client.
> > > > 1. On the client side I create a data document in which to store some
> > > > user annotations:
> > > > // root implements
> > > > org.waveprotocol.wave.model.conversation.Conversation
> > > > this.doc=
> > > > (ObservablePluggableMutableDocument)root.getDataDocument("ANNOTATION_DOC");
> > > > 2. on the client, I also create an element in which I will store the
> > > > user data,
> > > > // theMap is a HashMap<String,String>
> > > > this.child= doc.createChildElement(this.doc, "ENTRY_TAG",
> > > > theMap);
> > > > 3. on subsequent updates, the client code grabs the child
> > > > this.child = DocHelper.getFirstChildElement(this.doc,
> > > > this.doc.getDocumentElement());
> > > > 4. I then store the user data in the Attribute map of child above
> > > > this.doc.setElementAttribute(this.doc.asElement(child),
> > > > "USER_DATA",myUserData);
> > > > I can at least store the information in the attribute table.
> > > > My simple model is that when another user joins the wave, their client
> > > > should be able to access the attribute hash by asking for the same
> > > > data document, access the child, and then simply access attribute hash
> > > > as the "wave creator" client. That is, at the end of the
> > > > StagesProvider creation in the current version of the WebClient, #1
> > > > above is performed. At this point, I'm expecting that the newly joined
> > > > client will access the same (shared) data document.
> > > > Now, the "newly joined" client retrieves an empty attribute table. It
> > > > looks like the error on my part could range from not updating the data
> > > > document correctly, to some host of issues that I have not accounted
> > > > for.
> > > > I am hoping that the outline provides enough information, but would
> > > > happily provide more.
> > > > Thanks in advance.
>
> > > > --
> > > > 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%2bunsubscr...@goog
> > > > legroups.com>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/wave-protocol?hl=en.
--
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.
