incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael MacFadden <>
Subject Re: Maven Progress and Questions
Date Sat, 09 Jun 2012 19:49:08 GMT

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.


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 <> 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
>> Thanks.

View raw message