I subscribe to what's been said by Thomas. But let's have in mind that right now, we're only discussing code separation into projects/modules. After that, I'd be glad to help -as I've stated before to Michael - in getting a better client-server protocol definition and implementation.
Cheers, PP On 10/06/12 23:32, Thomas Wrobel wrote: > Is there any real need for different c/s protocols per client? > > Speaking as someone that would love to make a client, I assumed it > would be something that could connect to any Wave server. Much like > IMAP for email these days. Idealy a user should have the choice to use > any client with any server. > > If every client makers has to get there hands dirty in server code > making bespoke plugins wont it all become a mess? > > A think a standard c/s protocol - in any form - is better. > [/2 cents] > > That all said any moves to separate the client and server code out so > one can be worked on without the other I massively approve of :) > > On 9 June 2012 21:49, Michael MacFadden <[email protected]> wrote: >> Ali, >> >> I agree with what you are saying. right now the terms client and server are >> a bit confusing, because the "client" has both server side and client side >> components. Right now the "Server" contains the true server side stuff as >> well as the server side components of the web client. Right now the client >> server protocol is what goes between the GWT client and the "server-side" >> part of the web client. Unfortunately there is not a clear separate of the >> server side client components and the "real" server side stuff. >> >> I have always viewed the client server protocol is really something that we >> really don't need to "standardize" because it should really just be an >> internal implementation detail specific to the undercurrent GWT UI. A real >> client server protocol then would be needed. You mention the data API. >> Right now I am not sure that is mature enough. I think we need to look at >> that. What would a real client agonistic protocol look like. Would it be a >> Web Service? TCP Socket? >> >> One potential avenue would be to have a pluggable transport mechanism inside >> the true server, where you could deploy a plugin to communicate with an >> arbitrary client. That way WE would not have to define a client server >> protocol. We would just mature the an API that allows client plugin modules >> to hook in to the WaveBus, and define a plugin API. Then you could add >> arbitrary client handlers to the server. The first of which would be our >> GWT client. >> >> ~Michael >> >> >> On Jun 9, 2012, at 12:12 PM, Ali Lown wrote: >> >>> Ultimately, I would be interested in it being possible to create a new >>> server/client for WIAB, without being required to rework the entire >>> codebase (e.g. keep the exisiting GWT client, but have a new wave >>> server)t. >>> >>> So I see a distinction needing to be made in the server code between: >>> 1) 'WIAB server' -> responsible for delta transformation, federation, >>> persistence, robots, search implementation, data API >>> 2) 'CLIENT server' -> responsible for presenting the client GUI over HTTP. >>> with the client server responsible for receiving WebSocket traffic >>> (since that is a client implementation detail), and relaying the >>> actual information to the WIAB server somehow (is the data API >>> powerful enough to support a full client?) and with these 2 servers >>> being completely seperate running processes. >>> >>> Is this what others were thinking with a client-server split? >>> >>> Currently the entire codebase is shared code (as far as I understand), >>> with the 'server' (both 'CLIENT' and 'WIAB') existing mostly around >>> src/org/waveprotocol/box/server/. >>> The GWT interface for the client exists mostly around >>> src/org/waveprotocol/box/webclient and the rest of it would bundle >>> into a shared library. >>> >>> Ali >>> >>> On 9 June 2012 19:31, Michael MacFadden <[email protected]> wrote: >>>> All, >>>> >>>> Paulo and I have made a lot of progress on the maven build. We will be >>>> woking on getting the unit test working over the next week or so. >>>> >>>> One of the main goals is to separate the client code and the server code. >>>> Beyond that you would typically separate the modules based on either >>>> logical groupings of code our on how others might consume the code. To >>>> that end I have two questions. >>>> >>>> 1) Does any one have good insight in to what is client code, what is >>>> server code and what is shared? >>>> >>>> 2) What modules would be see being useful (wave-api?, robot-api? >>>> client-server protocol stuff?)? >>>> >>>> Thanks. -- Paulo Pires
