incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Wrobel <darkfl...@gmail.com>
Subject Re: Maven Progress and Questions
Date Sun, 10 Jun 2012 22:32:25 GMT
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 <michael.macfadden@gmail.com> 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 <michael.macfadden@gmail.com> 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.
>

Mime
View raw message