If you want to write a client/server protocol, it helps to have a client to test against. A small group of us started developing an emacs client for Wave, right now just using a simple lisp-like REPL to enable us to get a UI ready on the emacs side quickly. The eventual goal is to use a real client/server protocol. Discussing with a few colleagues, some liked XMPP, some preferred JSON. I don't have any strong preferences. If we use XMPP, it's like the federation protocol. If we use JSON, it's more like the actual protocol the web client uses. I was leaning to use JSON, personally, but both are workable.
If you are interested, our project is here: http://code.google.com/p/wave-client-for-emacs/ I'm cc'ing that project's mailing list as well. On Thu, Oct 1, 2009 at 4:43 AM, elliottcable <[email protected]>wrote: > > With the opening of the actual Google Wave preview today, I think it’s > high > time we re–opened the topic of the client–server (C/S) protocol. > > As the FAQ for this group says: > > > What is the client-server protocol? > > ------------------------------------------------- > > The focus of our open source and protocol work at this point is on > > the federation protocol, which is critical for getting inter-operable > > server implementations, that is, for allowing many other people to > > build Wave servers and have them interop with each other and with the > > Google Wave server. We have definitely heard the requests for defining > > a client-server protocol, but at this time the team doesn't have the > > time to put into such an effort. > > If you are interested in working on the client-server protocol we > > are happy to host that discussion here, and the client-server protocol > > as implemented in the open source server would be a fine place to > > start. > > Let’s get that discussion started, shall we? Federation is great, a > user > preview that dumb randoms can press pretty HTML buttons on is great, > but Wave > (the concept) is really quite useless until somebody can install a > Wave client > and talk to their Wave server of choice in that client, and read waves > from > other Wave users writing things in their own clients through their own > servers. None of that is possible until we (client developers) can get > started > writing our client libraries, GUI clients, web clients, and > programmatic > clients… and none of *those* are possible until we have a guarantee > that our > hard work and sweaty hours of coding will produce a product that will > be > useful on more than just Google’s Wave server. > > No offence to the Google Wave team (everything else they’ve come up > with is > pretty great), but the RPC/protobufs solution is… very much a non– > solution, > really. What, exactly, do we all want to see in this protocol? > > I personally am interested in seeing XMPP become not only the > foundation of > the federation protocol, but of the C/S protocol as well. When I first > heard > about Wave, before getting into the Sandbox, I was very excited; it > sounded > like a great idea, based on great tools (XMPP!). Unfortunately, I was > extremely disappointed to find that XMPP really has nothing whatsoever > to do > with Wave, and I’d like to see that remedied. > > Really, though, any sensible protocol that we can agree on would be > great. > Another option is possibly something involving JSON; that’d make > JavaScript > heavy–clients ridiculously easy to write for the web. > > Please, weigh in, and let’s get this hump over with! > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
