Hi Torben,
Someone correct me if I am wrong, but the FedOne server does not send
acknowledgements to the client as described in Operational
Transformation whitepaper. I believe this is part of the puzzle that
your are missing.
Furthermore, I can not see any reason why the server sends the
transformed operation back to the originating client when it
broadcasts the operation - that just confuses things. For example, it
was suggested that you can "you can compare the [transformed] docops
coming back down for equality"; this is just asking for false positive
matches. The server acknowledgement is the right mechanism to use
here.
You may like to read this thread:
http://groups.google.com/group/wave-protocol/browse_frm/thread/acca2ac22caeb04e/93d1b3e222679a27
And maybe look at my blog post:
http://www.thinkbottomup.com.au/site/blog/Google_Wave_Operational_Transform_and_Server_Acknowledgments
Your question is timely as there has been some discussion on defining
a client/server protocol. It is my opinion that this group doen not
understand the client side OT algorithms enough to define the
protocol. This is illustrated here by suggestions to add client-id's
(which I believe are not needed) to messages.
This opinion was stated here:
http://groups.google.com/group/wave-protocol/browse_frm/thread/184b66dfb3b9a24d/946cf09e5069d0f4#946cf09e5069d0f4
Someone in this community needs to spend some time understanding the
wave client and fixing FedOne. New comers to this forum seem to be
taking FedOne to be a reference implementation of both a wave client
and server - which it is neither.
Cheers,
Dan
On Jan 20, 1:50 am, Torben Weis <[email protected]> wrote:
> Hi,
>
> I have been pondering on how to support offline-working in QWaveClient.
> It is getting tricky when the TCP connection breaks accidentially,
>
> Let's imagine the client sent a delta to the server, the server processes
> it,
> but the client could not hear it because the connection is broken.
>
> Eventually the client will reconnect. Now it does not have a chance of
> seeing
> whether its last delta has reached the server or not.
> In general it seems next to impossible to tell whether any given server
> delta corresponds
> to a client delta, because deltas are transformed and do not carry IDs.
>
> Currently I see no quick solution.
> Two more complex solutions come to my mind:
> a) Introduce IDs in deltas. Unlikely because that would require Google to
> change
> its code heavily? Nevertheless, it would be nice because currently
> QWaveClient uses
> a most aweful hack to determin whether its delta has been processed by
> the server ...
> b) When connection to FedOne, the server should ask for a client ID.
> For each client ID & wavelet ID it keeps a persistent record about the
> version of the last submitted delta.
> Upon connect the client can query fedone for this version information.
> This would mean no modifications to the federation protocol, but it would
> require some fedone extensions.
>
> Any other ideas, suggestions?
>
> About the delta detection hack used in QWaveClient:
> According to the wave specs a client must have only one outstanding delta.
> Thus, it is important to find out whether a delta has been accepted or not
> to
> determine when the next delta can be sent.
> To solve this, QWaveClient waits until it receives a delta from the server
> which is authored by
> its own user, assuming that this is the server response to the delta
> QWaveClient has submitted itself.
> This hack can break if the same user connects with two QWaveClient instances
> and concurrently
> types in both instances (ok, unlikely, but still ...).
>
> Did I miss a trick of getting this right?
>
> Cheers
> Torben
--
You received this message because you are subscribed to the Google Groups "Wave
Protocol" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.
