incubator-wave-dev mailing list archives

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 <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.
--
Paulo Pires