Copy-n-Paste note: Where you see lots and lots of whitespace is a blip boundary. At least that's how it got pasted in. Wave Client Protocol Whitepaper Brainstorm
This wave is moderated to keep the responses down, do not be worried if your comments disappear. The result of each branch will summarized as part of the Whitepaper(IB) Related Waves: Interaction Flow: Wave Client Protocol Interaction flow Google Wave Conversation Model(Copied From Whitepaper): Google Wave Conversation Model Wave Definitions: Wave Definitions List Of Programming Languages Put Forward For Implementation: List Of Programmers Wave Data Model: Wave Data Model Requirements Functionality Handshaking Capabilities MUST have XML Schema? Operation Schemas (adding,OTing, etc) Recovery Persistent Changes / Temporary Storage Annotations (standard names as well? or just provisions) Push-based protocol. (must not rely on polling as the only means of fetching updates) Authentication agnostic (use OAuth in examples?) SHOULD have XMPP-based transport Compatible with BOSH / HTTP transports. Meta-Wavelets (Unread/Read Blips should be standardised) Bandwidth Throttling (blip by blip, character by character, word by word) Oct 13 Andrew Hyatt: This probably isn't necessary - just enable chunked messages. Oct 13 Daniel Renfer: Is this something built into the XMPP spec? Oct 13 Andrew Hyatt: Not that I know of, however I would be suprised if the XMPP spec would limit us to a character at a time. By making chunks variably sized, each side gets to decide. Oct 13 Daniel Renfer: How would it decide? Would this be something that is communicated, determined automatically by latency or platform capabilities? Oct 13 Andrew Hyatt: Probably any of those things (except for communication of diff size, which I don't see happening). From the protocol's point of view, it doesn't matter. Oct 13 Daniel Renfer: There should be 3 states of update for a connection. Update Incremental, Update Commit, and Update Never. Update Incremental is what we're now used to seeing. The rates are determined by load. Update Commit sends changes only "when done has been pressed" (for low capability clients) Update Never will not receive updates. The client must poll for changes manually. This is the default model for non-BOSH HTTP connections. Oct 13 Daniel Renfer: There is also the possibility of a 4th state. Update Summary. In this state, the client would receive notification of changes to waves, but not the content. I'm not convinced of the need for this one yet, however. Oct 13 Devyn Cairns: It could be useful, I guess. I'm sure someone could find a good use for it. Maybe for new message count-type things? Oct 13 Daniel Renfer: That's what I was thinking it would be used for. I should write out my idea for subscription views. Maybe others can tell me if the 4th state is wanted Oct 13 Devyn Cairns: Devyn: +1 Oct 13 Devyn Cairns: I'm going to hopefully write a little script for my custom UI... that will have a little count for Conky. Hopefully in Ruby. Oct 13 Daniel Renfer: I would love my recent waves to show up in that empty spot I have at the bottom of my conky output. A conky script is a perfect example of the need to support dumb, Update Never, HTTP access. You would be able to define a view for exactly what you would like to have displayed and have those updates be retrieved as an Atom feed. There's no need to have a full XMPP client for something like this. Oct 13 [email protected]: I agree, being able to get basic info from a curl / wget script is pretty handy Oct 13 Devyn Cairns: Still, I don't think Wave servers should have to start up an HTTP server.. I guess they can if they want to, but this isn't the right place for it. Oct 13 Daniel Renfer: http bindings would be an optional interface. The benefits of basing the model around Atompub would be that you only have to work out that model once, and it'll work for these or future formats. Oct 13 Devyn Cairns: Yeah... I agree, HTTP should be optional. That's more of an application-specific API, not something that needs to be standardized. Good to note for the future, if anyone asks. Oct 14 William Edney: Yea, exactly. If the protocol rides on top of XMPP, then you get the whole XMPP/BOSH thing 'for free' and the HTTP transport is happening at a lower-layer which you don't have to worry about. Oct 13 Devyn Cairns: Ah, so like "live typing/etc." and "after hitting done", and "nothing" etc. RESTful design. (operations in terms of CRUD operations on resource) Distinct URI for every element of wave. (blips, wavelets, etc.) MAY have PGP signing Support for alternate serializations. (json, yaml, etc.) Actions Wave create add wavelet read all history [a summary] fetch changes (requires index number, as given by "all history") Wavelet create add participant remove participant (no consensus on permissions, but at the present only bots can be removed) add blip read Blip create modify add contributor Oct 14 Daniel Renfer: Another question is if I create a blip, you change it, and then I revert or otherwise modify the content so that you no longer have any changes that contributed to this final state, are you still considered a contributor to that blip. Saying yes is easy, but not veryaccurate. Saying no would require some sort of "blame" operation where the contributions to a blip are clearly identified. Oct 14 Monika Adamczyk (and Angus Turner): Given that waves tracks any change, I would lean to saying 'yes' because even if there was no actual content change, the blip was touched and perhaps the change was already pushed to the server before it was removed in the client. Sort of similar to opening a file adding content and then removing it. Oct 14 Daniel Renfer: My comment didn't concern what is sent and stored on the server, but only what data is sent when the client asks the server "give me the list of contributors whose contributions make up the current state of this blip" and then there would be a seperate operation for "give me all users that have ever made a edit in the history of this blip." Oct 14 Monika Adamczyk: I am not sure I understand difference and purpose of these two operations. Oct 14 Daniel Renfer: suppose you have a blip (generally an IB) that has been edited many times by many people. You could have content that was added by one contributor early on that has been completely replaced by later editors. The first operation would list only the contributors that have added content still visible in the current state of the blip, while the other would list all of the people that have ever edited that blip for it's entire lifespan. Consider commands such as `git blame` that show who has written what lines of a program. (except that wave isn't line based) Oct 14 Monika Adamczyk: If I want to see the history of a blip, then I simply replay the wave and the issues of blame is moot. The history will tell me who and which order made changes. Oct 14 Daniel Renfer: The only real problem I see with that is it would not be possible to determine who did what to a blip without loading the full history of that blip. If we all agree that that is an acceptable loss, then this sort of advanced display could be handled entirely client-side and you can forget I said anything. Oct 14 David Hubbard: I'd rather see it a part of the client-server protocol, myself, but if not, it could be an extension, and thus a good test of the protocol's extendability. Oct 14 Daniel Renfer: A spec for searching and indexing waves is a natural extension of what we're doing here. We're just not ready for it yet. Oct 14 David Hubbard: As an extension, I'd hope it ends up being as good as if it were really in the protocol. That would simplify the initial protocol, for what it's worth. Oct 14 Angus Turner: I think that would be the way to go, create a protocol that can be extended easily, and thus have a simple base protocol Oct 14 Daniel Renfer: We should reference the OpenSearch protocol as a basis for integrated wave searching. (adding link to reference section) Oct 14 Angus Turner: ok, i'll take a read Note that this implementation of client doesn't have 'Cancel' button. The only time a change might be not tracked if client modifies blip in 'Draft' mode, although it is not clear to me what happens when someone wants to back out of 'Draft' based change (in this case having 'Cancel' button seems necessary. Oct 14 Daniel Renfer: I would assume that as long as no changes have been made to the content before the "draft-mode" is enabled, then the server has no idea that a change is being worked on and would have no way to track it. It's as if you wrote out a reply while offline, and then discarded that reply before syncing. Oct 14 Monika Adamczyk: That would also be my assumption how this should be implemented but how do you discard the reply offline if you have no 'Cancel' option. I assume the client detects every keystroke in the blip as 'blip content change' event because I have seen robots to be notified about this type of event on every keystroke. Oct 14 Daniel Renfer: A client must record all changes in a queue of unsynched commits. It is up to the client to decide how or when those commits are pushed out. Google wave pushes those changes out as soon as possible. That is why we are able to see the stream of keystrokes typed. (assuming the user's client/webpage has a reliable connection to the wave server.) An advanced client would be able to hold off on sending out those changes and allow the user to review, modify, and delete changes from their queue before allowing the client to send them off. Discarding an edit would simply be removing all edits related to that edit from the queue. Oct 14 Monika Adamczyk: Isn't this what the Draft mode is for? Even this client intends to support it at a later time. I mean, I would imagine you could have a client that always waits for user to approve changes and push them, but that's not different from any other IM client. The novelty and beauty of wave is that things are meant to happen in realtime. There was a use case in the ACL thread about using wave to communicate with a group of subordinates. (in this case, teacher / students.) If the contributor lististhe list of any user that has ever attempted to make modifications to that blip, (even if that change was canceled or reverted) then that studentsicon would always be displayed next to the teacher's icon, and you would never again be able to determine easily that all the content came from a single contributor. read delete Events Wave new Wavelet Wavelet contributor added contributor removed special? new blip Blip live update commit update header update (summary of changes, no content sent) deleted Extensions Search and Index Waves References Wave Expand On Federation Protocol Spec (http://www.waveprotocol.org/draft- protocol-specs/draft-protocol-spec) using a XMPP extension Wave Data Model: Wave Data Model Wave Definitions: Wave Definitions Conversation Model Spec Here: http://www.waveprotocol.org/draft-protocol-specs/wave-conversation-model (Google Wave Conversation Model ) FedOne Client and Server Here: http://code.google.com/p/wave-protocol Whitepapers (including a Google C/S Protocol): www.waveprotocol.org/whitepapers Access Controls: http://www.waveprotocol.org/whitepapers/access-control Wave Client Protocol Interaction flow XMPP Put Good XMPP Protocol Links here: Good XMPP Protocol Links Oct 14 Dale: I think we should kill of this wave and just put the links in here Oct 14 Angus Turner: mmm maybe, except there is no way to delete waves Oct 14 Dale: not specifically deleting the wave just stop using it, saves people jumping around, the too many clicks theory Oct 14 Angus Turner: as W3C says: "depricate" Oct 14 Dale (and Angus Turner): yeah but to what point, we already have other sections that are lists of links, maybe if it was a specific XMPP discussion that contained links it would be good Atom Atompub over XMPP: http://tools.ietf.org/html/draft-saintandre-atompub-notify-07 OpenSearch: http://www.opensearch.org/ Languages Implementation Languages: Python and/or Java (put your preferences here: List Of Programming [reference implementation] Languages ) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
