It might be a little out of date, but:
https://cwiki.apache.org/confluence/display/WAVE/Source+Code+Organization
might be a good start for anyone wanting to work on the client / server
/ common split. Anything with an x in both client and server columns
would obviously be common! ;-)
[Pablo: I don't know if your work already covers this, and is mergable
back into wave?]
John - long term aspirations are incredibly important, but Wave's
problems at the moment aren't due to a lack of aspiration (there are
plenty of great aspirations in the community, many of them shared by
many of us). My observation is that if wave is to survive at Apache we
need a focus on manageable incremental improvements - getting more
people involved in actually "doing".[1]
The client-server protocol is currently "defined" in this protobufs file:
https://git-wip-us.apache.org/repos/asf?p=incubator-wave.git;a=blob;f=src/org/waveprotocol/box/common/comms/waveclient-rpc.proto
but is effectively an implementation detail of the current combined
codebase.
Making a split between client and server (and common) will expose this
interface and make it more visible. Exposing the existing interface
(without worrying too much about improving it) seems like an excellent
initial step - and by making that interface more visible will hopefully
make it more obvious how we can improve it iteratively.
Dave
[1] I'm as guilty as many in doing plenty of talking, but not actually
contributing to the codebase or documentation in a meaningful way. Being
conscious of this, I try to keep out of most of the "blue sky"
discussions myself. I don't want my aspirations becoming a distraction
to people that have the time to actually "do" the changes that are of
interest to them.
On 25/03/15 00:56, John Blossom wrote:
Liking what I am hearing.
My ten cents:
client/server/common model is good for libraries, yes, but need
well-defined client APIs to allow multiple apps to access common data
stores. Otherwise you get more balkanisation and the data model never takes
off.
federation required, preferably in a way that will support sync/async
collaboration and store-forward data models.
Would like to see Wave 3.0 ideas considered.
All the best,
John Blossom
email: jblos...@gmail.com
phone: 203.293.8511
google+: google.com/+JohnBlossom
On Tue, Mar 24, 2015 at 4:32 PM, Thomas Wrobel <darkfl...@gmail.com> wrote:
On 24 March 2015 at 16:32, Dave Ball <w...@glark.co.uk> wrote:
Might it be better to have three "parts"?
- common
- server
- client
Common would contain the document and concurrency model etc. Client and
Server would both depend on Common. Common would compile to JS for the
Client, but Server would depend directly on Common so wouldn't need to
depend on the compiled javascript.
+1
I think this would be the best way to maintain compatibility between
client(s) and sever(s). Downside is people making non-Java clients (or
non-JS via GWT) would need their own common implementation.
But it wouldnt be any worse then now.
