On 5 January 2011 13:18, cearl <[email protected]> wrote: > Hi Dave, > Thanks. Could you suggest an appropriate place to instrument server or > client to check deltas? > My test of clients is as follows: I create wave1 on Client1, save the > annotation; I then log on as Client2 in the wiab client; as Client1 I > then add Client2 to the wave1; I then join the conversation on > Client2; at this point, Client2 creates an AnnotationWaveStore with > the same waveId, and gets "null" when getting from the map. Perhaps > checking deltas would be the thing to do, looks like this is all > logged... > > In terms of patch, would that be just a matter of placing diffs of my > StagesProvide and AnnotationWaveStore someplace? > > Follow the instructions at http://www.waveprotocol.org/code/submitting-code to upload a patch to our code review tool (even though you don't necessarily intend to commit the code).
> C > > On Jan 4, 8:09 pm, David Hearnden <[email protected]> wrote: > > That code looks quite correct. If both clients are connected, and can > > send and receive deltas on that wave, then after client 1 has executed > > addAnnotationToStore("foo", "bar"), then after enough time has passed > > for the delta to propagate to client 2, then client 2 should find that > > map.get("foo") is "bar", rather than null. > > > > Can you give any more information, or a patch? Can you verify that > > deltas are being sent and received by both clients? > > > > -Dave > > > > On Jan 4, 3:17 pm, cearl <[email protected]> wrote: > > > > > > > > > > > > > > > > > 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%[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]<wave-protocol%[email protected]> > . > 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.
