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.
