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
