Hi,
> I propose to send a tuple of > > epoch&sequence-number with each submit to reliably and easily detect > > resubmissions by remote wave servers and by clients. > > This is not a lost battle, I have taken up the debate with my > colleagues to add back (we did have one at some point) such a token. > We have not had time to fully debate this issue, but there is a fair > chance that we'll address this in the next revision. > I would really LOVE to see this re-introduced. Every decend protocol is using this technique to identify duplicates. PLEASE convince your colleagues to fix this. > > Yes, the protocol is more complicated with a commit notice. ... The commit > notice originates > from the c/s protocol, and I guess one could remove it from the > federation protocol and make servers only communicate changes once > they have committed. However, it would mean federated clients and > servers would be less responsive that the ones we have already > implemented. > I totally agree. Did anybody measure the difference? How long does it take google to write a few bytes to three GFS instances (well, a trade secret most likely :-) But how does this compare to the time it takes to submit wavelet-updates to several remote wave servers via XMPP? I guess that it is in the same order of magnitude, but I am just guessing. In general, handing out non-committed data is playing with fire, especially in a distributed system. Remote wave servers and clients must be able to roll back if they used uncommitted data that is aborted (i.e. never committed) later on. I am teaching this stuff every year at University and it is non-trivial. It is already difficult to do rollbacks inside a database. Now imagine rolling back servers and clients. Would you bet a thousand dollars that your implementation catches all possible side effects, i.e. that it performs a 100% roll back? See my other mail about the KISS principle. Same applies here, too. > > > c) The current C/S protocol is not able to handle deltas that have been > sent > > to the client and are revoked later (see previous example). We really > need > > the new C/S protocol. > > The client in FedOne does not do many things, as we have acknowledged. > I know, but my implemenation does :-) > We truly are working on getting a full client/server protocol out. We > will post more details on our timeline in the next week. > That's great news. Thanks. Torben > > regards, > Jochen > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- --------------------------- Prof. Torben Weis Universitaet Duisburg-Essen [email protected] -- 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.
