>> Since each delta must be processed by the federation host prior to >> submitting the next delta, this implies that a wavelet becomes >> un-editable (at best) or inaccessible (at worst) if the federation >> host goes offline. Caching in the federation remotes will alleviate >> the inaccessibility. > > Generally speaking, in my experience the wavelets become un-editable > as opposed to inaccessible.
I assume this is due to caching in the remote or the client. >> If a host goes offline temporarily that's just an inconvenience and >> isn't a major issue (except for the provider). But if a host suffers a >> permanent loss, or simply closes shop. All hosted wavelets would >> become inaccessible. Is it intended that in this situation >> participants simply fork the wavelet? Or will there be some future >> protocol version that allows for manual or automatic transfer of >> ownership to another server? > > I suspect (???) that only the server that hosts the wavelets keeps the entire > history of the wavelet. So if the server goes down you have already lost the > history, and forking based on the current version might be the easiest/only > solution. At the same time, losing the entire history makes me uneasy. I'm fairly certain that the entire history is required in order to obtain a current view of a wavelet. So all remotes that participated in a wave will have full history up to the last committed delta. So forking shouldn't be too difficult. > I previously had the alternative suggestion that keeping copies of the data > (including history) might be best done at the database level. I'm sure this will be a provider specific choice. If a provider retains/persists all history for all wavelets for which it has/had participants, then you as a customer would retain access to all wavelet history for which you where a participant. It is such a critical feature that I doubt that any serious provider would omit it. > Semi-related: I read somewhere a suggestion that it should be possible for a > user to create a fork of a wave if he/she is removed from the participant list > of the wave, from the point where they lost access. If so, this would reduce > my > concern that some upset person could remove my access to the information I > keep > in shared waves that I use to (for example) do my job (although the updates > I may miss could be just as important). If a remote can make requests for history for all versions up to the last version for which it was a participant, then removed participants would retain access to old revisions. All that's needed is a modification to the protocol (or reference implementation) that grants or limits history requests to only those versions that occurred prior to the last participant removal for that server. -Tad --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
