It seems like Walkaround has better defined and implemented c/s protocol, so it might be a good idea to take a loot at it.
On Tue, Jan 3, 2012 at 3:32 PM, Davide Carnovale < francesco.davide.carnov...@gmail.com> wrote: > Hi Yuri, > thanks a lot for the pointer. > Before i start looking into walkaround code though i'd like to ask you > something: why did you suggest this since they're using a different > protocol? > is there a plan to make WiaB c/s protocol adhere to walkaround one? or it > was just a suggestion to where i could copy some bits? > > D > > Il giorno 01 gennaio 2012 20:27, Yuri Z <vega...@gmail.com> ha scritto: > > > You might want also to take a look at > > Walkaround<https://code.google.com/p/walkaround/>, > > as they have it has somewhat different c/s protcol implementation. > > On Sun, Jan 1, 2012 at 9:23 PM, Davide Carnovale < > > francesco.davide.carnov...@gmail.com> wrote: > > > > > Michael, > > > your mail is enlightening, i thought websockets were "the choosen way" > > for > > > wiab to talk to the world, so that's why i concentrated on that and > > looked > > > for an android compatible implementation. at this point i'll reconsider > > > using another transport, though since i already have all the pieces > i'll > > > probably stick with websockets. > > > > > > As for the independence of the protocol from the transport, i totally > > > agree. what i envisioned so far is a set of api, that pretty much takes > > > user input and from that calculates deltas and send them to the server. > > > Viceversa, from the server it takes the incoming deltas, apply them to > > the > > > local state and outputs human readable text. in order to do this i > think, > > > but i'm still in an exploring stage, it's best to isolate something > like > > > (if not exactly) the old wave api, which will be used to generate > deltas > > > etc... and make some new classes that generates json (or gson or pst or > > > whatever is used now, still haven't looked into it) out of deltas that > is > > > ready to be sent to the server. packing this two parts into a jar > should > > do > > > the trick. > > > Obviously, once you have the json (or whatever) it doesn't really > matter > > > how you send it back and forth the server. how does this sound to you? > > > > > > As a side note, so far i've been able to make the android client > connect > > to > > > the wave server, so the first challenge i should face now is probably > > > authentication. i've seen though that the c/s protocol doc doesn't > > explain > > > how auth should be handled. > > > my first idea is sending a simple pair of username and encrypted > password > > > that the server could check against and an ack/nack message from the > > server > > > to let the client know what's going on. what do you all think? is there > > any > > > doc i'm missing that illustrates this? > > > > > > > > > D > > > > > > Il giorno 30 dicembre 2011 18:18, Michael MacFadden < > > > michael.macfad...@gmail.com> ha scritto: > > > > > > > Davide, > > > > > > > > Again, I am not an expert on the current client server protocol, but > I > > do > > > > have one comment to make. I think a good objective of whatever > > protocol > > > we > > > > come up with is that the protocol (i.e the message syntax, message > > > > semantics, data types, etc) be separated from the transport layer. I > > > would > > > > like to see a system where the client and server have a specific set > of > > > > messages that they exchange that conform to some API or messaging > > > > specification which is separate from how those messages are > transmitted > > > > between them. > > > > > > > > Right now the server, client, transport and client server protocol > are > > > all > > > > very tightly coupled in my opinion. I would like to see the wave > > server > > > be > > > > able to support many different kinds of remote clients. For example > an > > > > android app, or even a desktop application. In this case TCP, HTTP, > or > > > Web > > > > Services might be a good transport layer. For a browser based App > > > > WebSockets might be good. It would be great if the same code for > > forming > > > > and sending the messages could be used across all of these and have > > some > > > > abstraction for the underlying transport layer that could be swapped. > > > > > > > > In very loose pseudocode you could imagine something like: > > > > > > > > > > > > > > > > WaveServerTransport transport = new HTTPWaveTransport(" > > > http://myserver.com > > > > "); > > > > > > > > > > > > WaveService waveService = new WaveService(transport); > > > > WaveServiceMessageListener listener = WaveServiceMessageListener() { > > > > onMessageReceived(Message message) { > > > > .... > > > > } > > > > } > > > > waveService.addListener(listener); > > > > > > > > WaveMessage message = new DeltaMessage(Delta); > > > > waveService.sendMessge(message); > > > > > > > > The point here being that all of the code above is common regardless > of > > > > the transport layer with the exception of one line of code. I am not > > > sure > > > > if this is reasonable or not. My main concern here is that the > current > > > > wave client is a web based application and so WebSockets makes sense. > > > > However, I don't want to have to use WebSockets if I am writing and > > > iPhone > > > > app or a desktop client. But I also don't want to have a completely > > > > different "protocol" for each. > > > > > > > > > > > > ~Michael > > > > > > > > On Dec 29, 2011, at 4:27 PM, Vicente J. Ruiz Jurado wrote: > > > > > > > > > El 29/12/11 20:30, Davide Carnovale escribió: > > > > >> Hi all, > > > > >> I'd like to contribute to apache wave, in particular in the c/s > > > protocol > > > > >> area, my ideal goal (in wave terms) is to make a working c/s > > protocol > > > > and > > > > >> an android API that could later be used to build any kind of wave > > > > clients. > > > > >> (because my general goal, outside of wave scope, is to have a > > special > > > > >> purpose android client) > > > > >> > > > > >> First of all i have to say that neither websockets nor client > server > > > > >> communication is my area of expertise, so i'm sure i'll encounter > a > > > lot > > > > of > > > > >> troubles and will need your help various times. In fact this is my > > > first > > > > >> call for help. please bear with me... > > > > >> > > > > >> So far i've read (hopefully) all the docs i've found on the net, > > > spread > > > > >> between waveprotocol.org and incubator.apache.org and yet i don't > > > have > > > > a > > > > >> clear idea on the current state of wave in regard to the c/s > > protocol. > > > > >> > > > > >> For what i understood, there are 4 ways to talk to wave right now. > > > > >> 1 wave api > > > > >> 2 servlets > > > > >> 3 socket.io > > > > >> 4 websockets > > > > >> > > > > >> 1 is an heritage of the past and will be or is already > > discontinued, 2 > > > > is > > > > >> mostly a hack to enable caching on the webclient, 3 is the way > used > > by > > > > the > > > > >> webclient, 4 should be the "right" way but it's mostly > experimental > > (i > > > > >> guess because of the immaturity of the ws standard). > > > > >> > > > > >> is all this right? > > > > >> if yes, then the right way to implement the c/s protocol is via > > > > websockets > > > > >> and using this document [1] as a guidance, right? > > > > >> > > > > >> in this regard i've already started to experiment a bit. i'm using > > > this > > > > >> websocket implementation [2] on the android phone to connect to > the > > > wave > > > > >> server, without success to far. First of all, i couldn't figure > out > > > what > > > > >> version of the draft for ws is wave using atm, secondly, when i > try > > to > > > > >> connect (no matter the version i'm using) i get a 302 response. > > > > >> For what i could understand, 302 means the resource has been moved > > > and a > > > > >> redirect will happen, but this doesn't make sense to me in the > case > > of > > > > >> websockets. > > > > >> On the server side of things, i've hooked up the debugger to the > > wave > > > > >> server and put some breakpoints here and there, but none is ever > > > > triggered, > > > > >> so either i'm after the wrong classes or the server isn't getting > > any > > > > >> request at all. is there any kind of authentication i have to go > > > through > > > > >> before i can send messages to the server? or is the authentication > > > > itself > > > > >> done with messages? > > > > >> All i could find was this doc [3] but it describes only the > > webcliant > > > > >> authentication via jaas and i guess that doesn't apply to > > > websockets... > > > > >> > > > > >> so to recap, here's a list of questions that i hope will help me > > > tackle > > > > >> this problem from the right angle: > > > > >> - which is the right way to communicate with a wave server? (my > > guess > > > is > > > > >> websocket) > > > > >> - which ws standard draft if wave using atm? (my guess is [4]) > > > > >> - is the websocket lib i've choosen good for the client, or am i > > > forced > > > > to > > > > >> use jetty as wave seems to use that particular one? (my guess is > > that > > > > the > > > > >> lib is ok) > > > > >> - is authentication required with ws? what kind of auth is used? > > > > >> - from which class in the wave server should i start looking in > > order > > > to > > > > >> get an idea of what's going on? (my guess is > > > > >> WaveWebSocketServerChannel.java) > > > > >> - from a talk in the wave summit i understood there was an eclipse > > > > >> preference file with code style and other useful stuffs, but i > can't > > > > seems > > > > >> to find it, is it still true? > > > > >> > > > > >> any kind of help is much appreciated, including ideas, thoughts > and > > > > >> pointers to documentation i might have missed. > > > > >> > > > > >> Thanks everybody for reading this very long mail and happy new > year! > > > =) > > > > >> Davide > > > > >> > > > > >> [1] > > > > >> > > > > > > > > > > http://www.waveprotocol.org/protocol/design-proposals/clientserver-protocol > > > > >> [2] https://github.com/TooTallNate/Java-WebSocket > > > > >> [3] > > > > http://www.waveprotocol.org/protocol/design-proposals/authentication > > > > >> [4] > > > http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10 > > > > >> > > > > > > > > > > Hi David: > > > > > > > > > > First of all, I'm not a WIAB internals expert. But as I was > patching > > > the > > > > > websocket part these months I can give you some advices: > > > > > - WIAB now uses websocket (via jetty) for clients like chrome and > > > > > socket-io-java for other browsers like firefox. > > > > > - I recommend you to read: > > > > > + this list archive, for instance the thread "jWebSocket vs > > Atmosphere > > > > > vs Cometd" or my review request: "Jetty updated to version 8, > > socketio > > > > > patched and socket/socketio workaround" > > > > > > > > > > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-wave-dev/201110.mbox/thread > > > > > + > > > > > > http://www.ibm.com/developerworks/web/library/wa-reverseajax4/index.html > > > > > + Finally, I think that we should follow the recommendation of Tad > > > > > Glines (author of socket-io-java): > > > > > > > > > > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-wave-dev/201110.mbox/%3CCAKF7Ee1w1qgOuD6Em=BVAz5jWFrzfnsCKYZOd=+gdexhdnq...@mail.gmail.com%3E > > > > > (thanks indeed Tad by the way) > > > > > > > > > > About authentication, see the websocket code part in > > > > ServerRpcProvider.java. > > > > > > > > > > About Android (and mobile in general), I was asking myself if we > can > > > use > > > > > some library like: > > > > > http://code.google.com/p/gwt-mobile-webkit/ > > > > > https://github.com/dennisjzh/GwtMobile > > > > > to reuse client ui code. > > > > > > > > > > Bests, > > > > > -- > > > > > Vicente J. Ruiz Jurado > > > > > > > > > > http://comunes.org > > > > > http://ourproject.org > > > > > http://homes.ourproject.org/~vjrj/blog (@vjrj) > > > > > > > > > > "For the more there are who say 'Ours,'-not 'Mine'- by that much is > > > > > each richer ." [Dante on the joys of sharing (Purgatorio, XV)] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
