One note I'd like to make - Long term, offline client support will be critical for the success of wave. The client/server protocols need to be flexible enough to allow offline creation/modification/deletion of waves, wavelets, and documents.
The idea of combining data hashing with OT is fantastic - but it would be really nice to see that hashing extended to allow all content to be content-addressable. If the entire tree is content-addressable, (such that the hash of a wave is the hash of the hash of its wavelets, offline client synchronization becomes much, much simpler, and (to my mind) more scalable as content quantity grows. A content-addressable data model also makes backup/restores easier, when compared to sequential IDs. Google may already be doing this internally - I don't know. It would be fantastic to find out. Offline clients always are the most demanding of protocols. They need the most efficient synchronization, the best data chunking, and the content to be in an easily indexable form. In my opinion, the acid test for the C/S protocol would be to write a 'heavy client', using Gears for offline operation in similar fashion to Gmail offline. The best protocols are developed through the creation of multiple implementations with varying goals. A client with spotlight integration, a client for the iPhone, a Gmail Notifier-like client, etc. All of these will have different needs. Building a protocol before implementations always ends in over-complicate formats that require more client processing than needed. If each client creates their own, ideal protocol for their particular use, and brings them to the table - I believe a common protocol that is neither too complicate or too restricted would become obvious. Feel free to contribute ideas for clients that would exercise the protocol. Best Regards, Nathanael On Tue, Oct 13, 2009 at 11:13 AM, Stefan Langer <[email protected] > wrote: > > > > >> [...] > > I'm not. But this is open source, and there are official guidelines >> for submitting code. So I see no reason why it should not be accepted >> if it's written well and is beneficial to the project. Again, do >> notice the ifs ;-) > > [...] >> > This was merley an information for myself to see how you are affiliated and > wasn't ment as a discouragement!! > > I would like to hear the input of a google engineer on this as I think > their experience is a better than most of ours. Just my 2cts. > > So if I understand it correctly you are writing this library for the server > side of things and not for the client side? > If you need help or someone playing devils advocate ;) be sure to drop a > note and I will try to help as much as possible and time permits. > > Regards > Stefan > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
