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