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? 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%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.
