I touched on this issue at the end of the federation protocol talk at the summit. The problem is that without the full delta history there is no mechanism to authenticate the attribution of the contents, e.g., if a blip is authored by someone from another domain than the host of the wavelet. I worry that it will require a significant amount of protocol engineering to solve that problem.
Of course, it would be a nice feature to have. Without it in the current protocol the latency from a person from a new domain is added to a wavelet till the wavelet can be rendered in the person's browser depends on the length of the wavelet's delta history (because it has to be transfered in full to the new domain's wave server before it can calculate the wavelet's current state). I welcome any good ideas but I don't think it's the easiest or the most pressing protocol issue to solve. Soren On Sun, Nov 21, 2010 at 5:32 AM, Alex North <[email protected]> wrote: > Hi Torben, > Unforunately due to some ugliness in our interpretation of the state from > deltas it's not possible to construct a single delta to take a wavelet to > arbitrary state. You would need a new snapshot protobuf that could capture, > for example, the multiple contributors to a single document. The > client/server protocol has something like that: > http://code.google.com/p/wave-protocol/source/browse/src/org/waveprotocol/box/server/waveserver/waveclient-rpc.proto. > However, I would suggest against adding it. Firstly, if you add it you're > adding to the abstract federation protocol, so you'd need to add it to XMPP > as well. But secondly, it's not necessary. Don't add something just because > it's nice. Let's try to keep the protocol minimal and add something like a > current snapshot request if and only if the protocol proves inadequate > without it. > A. > > On 20 November 2010 07:12, Torben Weis <[email protected]> wrote: >> >> Hi, >> I am just implementing protobuf support in lightwave's HTTP transport. >> I wondered what I should return if someone simply tries to get a wavelet. >> The current spec says you have to specify which deltas you want >> GET >> http://hosting-server/wave/fed/data/<wavelet-id>?v1=<start-version>&v1hash=<start-version-hash>&v2=<end-version>&v2hash=<end-version-hash>&limit=<bytes> >> and the return type is >> >> message ProtocolWaveletHistory { >> repeated bytes deltas = 1; >> >> >> optional int64 truncated = 2; >> >> >> optional int64 commit_notice = 3; >> >> >> } >> >> When just asking for >> GET http://hosting-server/wave/fed/data/<wavelet-id> >> I would like to simply return a snapshot. I assume the best way of doing >> this is to return a constructed delta that mutates the empty wavelet to the >> current state. Any other idea? >> Furthermore, do we want to have this in the HTTP spec, i.e. a way of >> quickly retrieving the snapshot of a wave via HTTP GET? >> 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. > > -- > 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. > -- 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.
