Handling concurrent/simultaneous state changes.

[GoogleCodeExporter]

Since gadget has shared state, it is common that it state can be changed
simultaneously by several users.
And when these changes apply to he same fields - last change override all
others.
This is quite not wave-way.

Some native handling of concurrent changes in gadget would be just nice.

Original issue reported on code.google.com by qwigly...@gmail.com on 8 Oct 2009 at 5:32

[GoogleCodeExporter]

We cannot do OT on the gadget state, as developers may be storing structured 
data 
(like serialized JSON strings) as the state values. OT could not guarantee the 
validity of the data.

I recommend storing keys per-participant as often as possible, as then users 
cannot 
override eachother. You can then use timestamps to see which participant 
modified 
something most recently, if needed, and use their value.

What is your use case?

Original comment by pamela.fox on 11 Oct 2009 at 2:26

• Changed state: NeedsMoreInfo

[GoogleCodeExporter]

Such design may bring developers to invent their own OT for gadgets state.
Some help on side of gadget API somewhere in wave.util could simplify that task.

Original comment by qwigly...@gmail.com on 11 Oct 2009 at 3:40

[GoogleCodeExporter]

Can you describe the use case?

We are thinking about letting developers embed OT-enabled text fields in their 
gadgets, 
so that they can have OT for text input. Would that satisfy you?

Original comment by pamela.fox on 11 Oct 2009 at 9:24

[GoogleCodeExporter]

my usecase is imaginary - i thought about providing meta-info about document in 
style
of rdf-like description (just structured data with key/value pairs (where 
values can
as well be lists)), so that users can create/update/delete key/values.

solution is to create separate fields for command issued from every participant,
and then process every command received in delta.
this provides ability to partialy modify gadget state.
but sequence of deltas may happen to contain operations that should happen not 
in
order of receivement and get in conflict.
that's exactly what OT deals with, in general.

i have not ever tried this to implement, so cannot provide exact cases.

and personally i have no idea how to make OT on structured data.
most of times operations should not conflict at all, when being updated by 
descrete
commands with fields referenced by names.

the worst case seems to be changing parent:
opA: s/{ foo: { b:bar, z:baz } }/{ thisFoo: { b:bar, z:baz } }/
opB: s/{ foo: { b:bar, z:baz } }/{ foo: { b:bazar, z:baraz } }/
and also updating lists:
opA: s/{ foo: [1,2,3,4] }/{ foo: [1,2,3,4,5] }/
opB: s/{ foo: [1,2,3,4] }/{ foo: [1,2] }/

Original comment by qwigly...@gmail.com on 12 Oct 2009 at 2:59

[GoogleCodeExporter]

P.S.
If I recall correctly, Operational Transformation on widgets' state was actually
implemented in Jupiter system - a farther of GoogleWave.
The Paper [1995] mentions input widgets like Numeric, TextList, TypeIn, 
Typescript.
most are based on the same text stream operations insert/delete/move.

But in general, i'm thinking of more broad thing - 
making OT for operations upon structured object (either json or xml),
which are not just insert/delete.
It definitely needs a serious discussion.

Original comment by qwigly...@gmail.com on 12 Oct 2009 at 7:16

[GoogleCodeExporter]

pamela.fox said "We are thinking about letting developers embed OT-enabled text 
fields 
in their gadgets, so that they can have OT for text input. Would that satisfy 
you?"

In the current Wave client UI, when a second participant overwrites a blip from 
a 
first participant, playback can be used to get the previous blip and to know 
who was 
the first writer and who was the second. Similarly if a gadget had access to 
the 
history of what it stored in the wave, it could help resolve some conflicts.

Original comment by razorcam...@gmail.com on 12 Oct 2009 at 10:08

[GoogleCodeExporter]

pamela.fox said "You can then use timestamps to see which participant modified 
something most recently, if needed, and use their value."

In the current Gadget API header file 
"http://wave-api.appspot.com/public/wave.js"
 the function wave.getTime is only in this line:
wave.getTime = function() {
  return(new Date).getTime()
};

This means that wave.getTime returns the local time of the browser of a 
praticipant. 
Timestamps can only be pratical if there is a shared "wave time", like the time 
stamps we find attached to the commit of a file in a CVS server.

Original comment by razorcam...@gmail.com on 12 Oct 2009 at 10:20

[GoogleCodeExporter]

In the way of reimplementing OT for gadgets, what matters is the time when 
dalta was
received on server.
There seems no way to discover it.

Original comment by qwigly...@gmail.com on 13 Oct 2009 at 12:50

[GoogleCodeExporter]

Yes, I agree - our API should reveal a server-based timestamp. getTime() does 
not yet 
offer this. We have an internal request tracking that need already, but please 
file a 
public request so that you can track and discuss that request specifically.

Original comment by pamela.fox on 13 Oct 2009 at 1:06

[GoogleCodeExporter]

Bug #285

(feeling myself as issue flooder.)

Original comment by qwigly...@gmail.com on 13 Oct 2009 at 1:29

[GoogleCodeExporter]

On wave.getTime, it'd really be useful for synchronization and other purposes 
to get
the timestamp from the wave server.

Client timestamp is very inaccurate, modifiable and unreliable.

I was puzzled about its purpose when i read the implementation since js coders 
can
just do their own function(){return(new Date).getTime()}

Original comment by the1g...@gmail.com on 25 Dec 2009 at 10:28