On Fri, Sep 4, 2009 at 11:11 AM, Tad Glines<[email protected]> wrote:
>
>> > 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.

Yes, it is our plan to put size limits into the spec. We're working on
defining a limit that's effective and cheap to compute by all parties,
it has to account for the size of all the characters, tags,
attributes, annotations, and participants in documents and wavelets.

>> > 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.

The updates are signed by the providers of the users who author the
updates, which may be different from the provider who hosts the
wavelet.

> If the version hash was included in the update signature, then
> the content at that version is easily verified without looking at the
> history.

The version hash is presently a hash of the update history, not a hash
of the snapshot.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to