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.
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 <charles.ce...@gmail.com> 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 wave-protocol@googlegroups.com. > To unsubscribe from this group, send email to > wave-protocol+unsubscribe@googlegroups.com<wave-protocol%2Bunsubscribe@goog legroups.com> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en.
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 <ano...@google.com> 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 <charles.ce...@gmail.com> 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 wave-protocol@googlegroups.com.
> > To unsubscribe from this group, send email to
> > wave-protocol+unsubscribe@googlegroups.com<wave-protocol%2Bunsubscribe@goog legroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/wave-protocol?hl=en.
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:
// 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 <charles.ce...@gmail.com> 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 <ano...@google.com> 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 <charles.ce...@gmail.com> 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 wave-protocol@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > wave-protocol+unsubscribe@googlegroups.com<wave-protocol%2Bunsubscribe@goog legroups.com>
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/wave-protocol?hl=en.
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 <hearn...@google.com> 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:
> // 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 <charles.ce...@gmail.com> 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 <ano...@google.com> 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 <charles.ce...@gmail.com> 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 wave-protocol@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > wave-protocol+unsubscribe@googlegroups.com<wave-protocol%2Bunsubscribe@goog legroups.com>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/wave-protocol?hl=en.
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 <charles.ce...@gmail.com> 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 <hearn...@google.com> 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:
> > // Now interact with the data doc using a plain map interface.
> > dataMap.put("myKey", "myValue");
> > String other = dataMap.get("otherKey");
> > ...
> > }
> > 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 <charles.ce...@gmail.com> 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 <ano...@google.com> 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 <charles.ce...@gmail.com> 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 wave-protocol@googlegroups.com.
> > > > > To unsubscribe from this group, send email to
> > > > > wave-protocol+unsubscribe@googlegroups.com<wave-protocol%2Bunsubscribe@goog legroups.com>
> > > > > .
> > > > > For more options, visit this group at
> > > > >http://groups.google.com/group/wave-protocol?hl=en.
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 <hearn...@google.com> 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 <charles.ce...@gmail.com> 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 <hearn...@google.com> 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:
> > > // Now interact with the data doc using a plain map interface.
> > > dataMap.put("myKey", "myValue");
> > > String other = dataMap.get("otherKey");
> > > ...
> > > }
> > > 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 <charles.ce...@gmail.com> 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 <ano...@google.com> 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 <charles.ce...@gmail.com> 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 wave-protocol@googlegroups.com.
> > > > > > To unsubscribe from this group, send email to
> > > > > > wave-protocol+unsubscribe@googlegroups.com<wave-protocol%2Bunsubscribe@goog legroups.com>
> > > > > > .
> > > > > > For more options, visit this group at
> > > > > >http://groups.google.com/group/wave-protocol?hl=en.
On 5 January 2011 13:18, cearl <charles.ce...@gmail.com> 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?
> On Jan 4, 8:09 pm, David Hearnden <hearn...@google.com> 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 <charles.ce...@gmail.com> 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 <hearn...@google.com> 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:
> > > > 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 <charles.ce...@gmail.com> 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 <ano...@google.com> 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 <charles.ce...@gmail.com> > 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 > wave-protocol@googlegroups.com. > > > > > > > To unsubscribe from this group, send email to > > > > > > > wave-protocol+unsubscribe@googlegroups.com<wave-protocol%2Bunsubscribe@goog legroups.com> > <wave-protocol%2Bunsubscribe@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 wave-protocol@googlegroups.com. > To unsubscribe from this group, send email to > wave-protocol+unsubscribe@googlegroups.com<wave-protocol%2Bunsubscribe@goog legroups.com> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en.
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.
On 6 January 2011 07:37, cearl <charles.ce...@gmail.com> wrote:
> -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to wave-protocol@googlegroups.com. > To unsubscribe from this group, send email to > wave-protocol+unsubscribe@googlegroups.com<wave-protocol%2Bunsubscribe@goog legroups.com> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en.
> 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.
> On 6 January 2011 07:37, cearl <charles.ce...@gmail.com> wrote:
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Wave Protocol" group.
> > To post to this group, send email to wave-protocol@googlegroups.com.
> > To unsubscribe from this group, send email to
> > wave-protocol+unsubscribe@googlegroups.com<wave-protocol%2Bunsubscribe@goog legroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/wave-protocol?hl=en.
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
On Jan 12, 9:58 pm, cearl <charles.ce...@gmail.com> wrote:
> On Jan 12, 5:57 pm, Alex North <ano...@google.com> wrote:
> > 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.
> > On 6 January 2011 07:37, cearl <charles.ce...@gmail.com> wrote:
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "Wave Protocol" group.
> > > To post to this group, send email to wave-protocol@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > wave-protocol+unsubscribe@googlegroups.com<wave-protocol%2Bunsubscribe@goog legroups.com>
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/wave-protocol?hl=en.
> 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
> On Jan 12, 9:58 pm, cearl <charles.ce...@gmail.com> wrote:
> > Thanks
> > On Jan 12, 5:57 pm, Alex North <ano...@google.com> wrote:
> > > 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.
> > > On 6 January 2011 07:37, cearl <charles.ce...@gmail.com> wrote:
> > > > --
> > > > You received this message because you are subscribed to the Google Groups
> > > > "Wave Protocol" group.
> > > > To post to this group, send email to wave-protocol@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > wave-protocol+unsubscribe@googlegroups.com<wave-protocol%2Bunsubscribe@goog legroups.com>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/wave-protocol?hl=en.
