Figuring out data document update model

[cearl]

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.

[Alex North]

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.

Post by cearl
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
// 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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[cearl]

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

Post by Alex North
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.

Post by cearl
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
     // 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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[David Hearnden]

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

Post by cearl
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

Post by Alex North
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.

Post by cearl
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
     // 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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[cearl]

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

Post by David Hearnden
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
  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

Post by cearl
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

Post by Alex North
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.

Post by cearl
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
     // 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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[David Hearnden]

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

Post by cearl
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.
  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

Post by David Hearnden
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
  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

Post by cearl
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

Post by Alex North
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.

Post by cearl
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
     // 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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[cearl]

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

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

Post by cearl
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.
  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

Post by David Hearnden
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
  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

Post by cearl
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

Post by Alex North
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.

Post by cearl
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
     // 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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[Alex North]

Post by cearl
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).

Post by cearl
C

Post by David Hearnden
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

Post by cearl
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.
public AnnotationWaveStore(Conversation root, WaveId waveId) {
this.doc= (ObservableDocument) root.getDataDocument(WAVE_ANNOT);
this.map =

DocumentBasedBasicMap.create(DefaultDocumentEventRouter.create(this.doc),

Post by David Hearnden

Post by cearl
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

Post by David Hearnden
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
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",

Post by David Hearnden

Post by cearl

Post by David Hearnden
"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

Post by cearl
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

Post by Alex North
What you've described sounds approximately correct, though there

are many

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North
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

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North
be expecting to submit it to wave).
A.

Post by cearl
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

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
on the update mechanics that I need to take care of. I can't

seem to

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
get my simple model to work for multiple users of the same

wave.

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
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

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
// root implements
org.waveprotocol.wave.model.conversation.Conversation
this.doc=

(ObservablePluggableMutableDocument)root.getDataDocument("ANNOTATION_DOC");

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
2. on the client, I also create an element in which I will

store the

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
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

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
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

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
should be able to access the attribute hash by asking for the

same

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
data document, access the child, and then simply access

attribute hash

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
as the "wave creator" client. That is, at the end of the
StagesProvider creation in the current version of the

WebClient, #1

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
above is performed. At this point, I'm expecting that the newly

joined

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
client will access the same (shared) data document.
Now, the "newly joined" client retrieves an empty attribute

table. It

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
looks like the error on my part could range from not updating

the data

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
document correctly, to some host of issues that I have not

accounted

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
for.
I am hoping that the outline provides enough information, but

would

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
happily provide more.
Thanks in advance.
--
You received this message because you are subscribed to the

Google Groups

Post by David Hearnden

Post by cearl

Post by David Hearnden

Post by cearl

Post by Alex North

Post by cearl
"Wave Protocol" group.
To post to this group, send email to
To unsubscribe from this group, send email to
.
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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[cearl]

Ok, the patches for the files involved were posted as issues 472001<http://codereview.waveprotocol.org/472001/show>
- 474001 <http://codereview.waveprotocol.org/474001/show>. I apologize for
not realizing that they all should have been submitted as the same patch
set. I see that this group is now deprecated...

[Alex North]

Logging deltas and trying to understand what's happening to the underlying
data should definitely help you.

I had a brief look at your patches. I don't really understand the second
one. In the first one, I can see that the maps member never has anything put
in it. I suggest writing a suite of unit tests to ensure your code does the
right thing before trying to figure out why it's not working across multiple
clients. Tests will also help document what you're trying to achieve for
other readers.

Post by cearl
Ok, the patches for the files involved were posted as issues 472001<http://codereview.waveprotocol.org/472001/show>
- 474001 <http://codereview.waveprotocol.org/474001/show>. I apologize
for not realizing that they all should have been submitted as the same patch
set. I see that this group is now deprecated...
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[cearl]

Thanks

Post by Alex North
Logging deltas and trying to understand what's happening to the underlying
data should definitely help you.
I had a brief look at your patches. I don't really understand the second
one. In the first one, I can see that the maps member never has anything put
in it. I suggest writing a suite of unit tests to ensure your code does the
right thing before trying to figure out why it's not working across multiple
clients. Tests will also help document what you're trying to achieve for
other readers.

Post by cearl
Ok, the patches for the files involved were posted as issues 472001<http://codereview.waveprotocol.org/472001/show>
 - 474001 <http://codereview.waveprotocol.org/474001/show>. I apologize
for not realizing that they all should have been submitted as the same patch
set. I see that this group is now deprecated...
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[cearl]

Hi,
Thanks. I've been able to verify that the problem was due to a parse
error caused by data format I was hoping to use.
I was attempting to store JSON strings directly in the map, e.g.:
{"x":551,"y":326,"width":20,...}
I'm generating the JSON from toString() of existing JSON objects, so
I'm assuming that the JSON text is valid.
However, I note the error
org.codehaus.jackson.JsonParseException: Unexpected character
('x' (code 120)): was expecting comma to separate OBJECT entries
when the string is received on the server.

Just storing the JSON in the map directly seems to fix the problem.
This probably means that my model of Document base map is
shallow...the "json -> map" fix suffices I think...
C

Post by cearl
Thanks

Post by Alex North
Logging deltas and trying to understand what's happening to the underlying
data should definitely help you.
I had a brief look at your patches. I don't really understand the second
one. In the first one, I can see that the maps member never has anything put
in it. I suggest writing a suite of unit tests to ensure your code does the
right thing before trying to figure out why it's not working across multiple
clients. Tests will also help document what you're trying to achieve for
other readers.

Post by cearl
Ok, the patches for the files involved were posted as issues 472001<http://codereview.waveprotocol.org/472001/show>
 - 474001 <http://codereview.waveprotocol.org/474001/show>. I apologize
for not realizing that they all should have been submitted as the same patch
set. I see that this group is now deprecated...
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[cearl]

Problem solved, the json is indeed malformed. Thanks for the critique
and sorry to take your time...
C

Post by cearl
Hi,
Thanks. I've been able to verify that the problem was due to a parse
error caused by data format I was hoping to use.
   {"x":551,"y":326,"width":20,...}
I'm generating the JSON from toString() of existing JSON objects, so
I'm assuming that the JSON text is valid.
However, I note the error
    org.codehaus.jackson.JsonParseException: Unexpected character
('x' (code 120)): was expecting comma to separate OBJECT entries
when the string is received on the server.
Just storing the JSON in the map directly seems to fix the problem.
This probably means that my model of Document base map is
shallow...the "json -> map" fix suffices I think...
C

Post by cearl
Thanks

Post by Alex North
Logging deltas and trying to understand what's happening to the underlying
data should definitely help you.
I had a brief look at your patches. I don't really understand the second
one. In the first one, I can see that the maps member never has anything put
in it. I suggest writing a suite of unit tests to ensure your code does the
right thing before trying to figure out why it's not working across multiple
clients. Tests will also help document what you're trying to achieve for
other readers.

Post by cearl
Ok, the patches for the files involved were posted as issues 472001<http://codereview.waveprotocol.org/472001/show>
 - 474001 <http://codereview.waveprotocol.org/474001/show>. I apologize
for not realizing that they all should have been submitted as the same patch
set. I see that this group is now deprecated...
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.