> > Is there a (possibly assumed) document size limit? > > The protocol spec currently doesn't specify this. However, the next > revision of the spec will include support for coded error messages > including one encouraging a remote server to stop sending so much > data, or that the document they are working on is too large.
This sounds like any size limits will be left up to the server implementation. If this limit isn't available to all servers participating in a wave, then interoperability issues might arise. One way to avoid this is to add some wavelet properties that define wave limits. Since the wavelet is hosted on the creating server, this would allow all remote servers to stay within the defined wavelet limits. > > As far as I can tell, the only way for a remote server (or client) to obtain > > the current version of a wavelet/doc is to reconstruct it from the history. > > This seems like it would be suboptimal in cases where a wavelet has a large > > history. Am I missing something? > > It's important for you to request the entire history as each delta > will be signed by the originating party. If you optimise the process > by sending a snapshot (which you might want to do from server to > client, depending on your trust model) you lose the ability to verify > that a wavelet was actually written by its claimed author. As I understand it, all wavelet updates are signed by the federation host. If the version hash was included in the update signature, then the content at that version is easily verified without looking at the history. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
