Dave - Thanks for your reply, thats incredibly usefull and has cleared up quite a few points for me - especially the usage of the word "blip".
I know its kinda an impossible question to answer; but any idea on the timescale of the simpler c/s protocol ? Not much point doing our own implementation if theres a more simple/newer c/s going to replace it within weeks. If, however, its 6 months away, then clearly its better for us to learn how to make our own and update as the need arises. Thanks again, Thomas On 2 February 2011 15:49, David Hearnden <hearn...@google.com> wrote: > Hi Thomas, > > On Wed, Feb 2, 2011 at 10:53 PM, Thomas Wrobel <darkfl...@gmail.com> wrote: > >> I got a few basic questions about the blip creation process. >> I've been working on a Android client with a group and so far we have >> been using a modified version of the old FedOne code (specifically we >> made "fedone-android-client-api-0.2.jar" by porting >> "fedone-client-console-0.2.jar") so I haven't had to look too much >> into the nitty-gritty of the communication myself. We managed to get >> read/write working crudely on the old server (like, 5 months old >> version) >> >> Now with the changes made with WiaB, like websocket based >> communication, I think I need to understand the c/s protocol better in >> order to make our client compatible with the latest version of the >> server, so hence a few questions; >> >> 1. Will WiaB going forward, be focusing on just websocket >> communication from the client? As I understand it, the webclient at >> the moment uses either websockets or socket IO....is it likely that >> both of these will be maintained, or is Socket IO just a stop-gap till >> webbrowsers support websockets more universally? >> > > socket.io's interface is the same as websocket, and if websocket is present, > it just uses that, so using socket.io on websocket-enabled browsers should > have virtually no complexity or runtime cost. If/when all the browsers that > WIAB cares about support native websockets, then removing socket.io and > using raw websockets directly would be almost a no-op due to the similarity > in their API, so I don't think it's a maintenance issue. > > > >> 2. When a client creates a new blip, how is its ID handled. Does the >> client create a temp ID that is then updated by the server sending >> back a "real" ID? Or does the server tell the client what is a new >> free ID in advance of blip creation? >> > > The word 'blip' is historically overloaded unfortunately, and it depends on > which level it applies. > > At the core, a wavelet is a collection of named documents (formerly called > blips, but not anymore). There is no creation of documents - all documents > implicitly exist in the empty state. As such, clients do not create > documents, they just start mutating them. OT resolves collisions with > concurrent mutations. > > On top of the core wavelet model is a conversation model, which is > structured units of conversation (threads and blips, the latter being the > new meaning of 'blip'). The structure of the conversation is stored in a > document in the wavelet (that document is named 'conversation' in the > wavelet, and is called the manifest document). When a client creates a new > conversational unit (a blip), it summons an ID for it, adds an entry into > the manifest referring to the new blip, and then starts mutating the blip's > document. All this conversation stuff is thought of as an application level > model that sits on top of the core wave platform (which is just disconnected > documents in a wavelet, with no relationships between them). The client's > ID generation scheme for blips is seeded by a unique id given to the client > on startup. Currently, the generation scheme is not cryptographically > strong, in that subsequent IDs are predictable. A malicious agent could of > course predict an active client's next blip ID, and cause problems for them. > However, the seeds should be cryptographically strong, so that ID > collisions from well-behaved clients are very unlikely. Making a client's > ID sequence unpredictable should be trivial (but is a piece of work that has > not been done). > > >> 3. Whats currently good place to start with a c/s android port? We >> managed to port fedone-client-console-0.2.jar before (more or less), >> is there a similar place we should start from thats more upto date? >> Or do we have to implement a protocol from scratch? >> We are basically interested in connection, and reading/write/edit >> blips - we aren't concerned with widgets or any layout related code. >> > > You'll need to use the conversation model, in order to have a consistent > interpretation and mutation contract with the conversation manifest. Have a > look at wave/model/conversation. The API (Conversation) is pretty simple, > and the implementation (WaveBasedConversationView) just needs a wave object. > The conversation model does not prescribe any UI - it's disconnected from > widgets or layout - so hopefully that's a good place for you to start! > > But for that you'll need a working core wave platform. We're in the process > of rolling out a simpler and more flexible c/s protocol ( > http://www.waveprotocol.org/protocol/design-proposals/clientserver-protocol), > so I'm not sure what the best answer is for you. > > -Dave >
