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: An Open Source implementation of Google Drive Realtime API
Date Tue, 08 Jul 2014 14:32:15 GMT
You miss understood me. I wasn't saying it used the same protocol, merely
it seemed to have much of the same functionality.

>"Wave's code is all-inclusive, it is difficult to divide each module, so
>every part is hard to be used separately, hard to be replaced with other
>implementations, and hard to be integrated into other projects."

Which is why I was suggesting rather then trying to patch wave into shape,
if its possible instead for this to grow to matches waves feature set.
This seems to already have separated client and server code - something I
always thought was a key division wave has lacked and has held it back from
having mobile clients made for it.

Wave has always been impressive - but its also been years since Google
abandoned it, and despite some effort under Apache is hasn't progressed far
since. Its never nice abandoning code, but I think there is at least some
arguments to be said for building something that can do what wave can, but
from a fresh code/protocol standpoint.
My (simple) understanding of the main difference in functionality of this
protocol between this and wfp is the lack of federation. Is that correct?

>"Benefit from the distributed publish/subscribe event bus across
>server/browser/iOS/Android and no ui specific code, it is easy to implement
>client libraries on multiple platforms."

Well, exactly!
This is something that seems fairly easy with this realtime store, but
something that (at least for me) has been far too much effort to even start
to work out how to do with wave.
Someone could even use libgdx or PlayN to build cross platform clients if
they wished here.




~~~
Thomas & Bertines online review show:
http://randomreviewshow.com/index.html
Try it! You might even feel ambivalent about it :)


On 8 July 2014 16:11, 田传武 <i@goodow.com> wrote:

> inline
>
> On Tue, Jul 8, 2014 at 7:42 PM, Thomas Wrobel <darkflame@gmail.com> wrote:
>
> > Thats really cool work.
> > Seems to work slickly, and theres mobile library code already.
> >
> > Someone needs to make a ven diagram of various communication techs and
> > their features. As I understand it this has the functionality of the wave
> > protocol except for the federation right?
> >
>
> No, it does not follow the wave protocol, it implemented Google Drive
> Realtime API <https://developers.google.com/drive/realtime/>
> realistically.
>
>
>
> >
> > Just a random thought, but seeing as theres occasionally calls for the
> Wave
> > code base to be scrapped and recreated (faster/better/stronger/neater...)
> > would it make sense to build a new WFP out of this, rather then trying to
> > wrangle the existing code into shape?  Or is that a crazy idea?
> >
>
> Wave's code is all-inclusive, it is difficult to divide each module, so
> every part is hard to be used separately, hard to be replaced with other
> implementations, and hard to be integrated into other projects.
>
> Wave is a great product, but not a good library. Just like ShareJS,
> realtime-store has there major modules, each module can be used separately:
>
> 1) realtime-operation <https://github.com/goodow/realtime-operation>  An
> operational transform library for Java, currently only supports json-like
> data type, no xml support.
>
> 2) realtime-channel <https://github.com/goodow/realtime-channel>
> Distributed
> publish/subscribe event bus which penetrates from server to
> browser/iOS/Android, currently use SockJS for browser, WebSockets for
> iOS/Android, ant can be implemented using MQTT or XMPP.
>
> 3) realtime-store <https://github.com/goodow/realtime-store> Persistence
> layer, currently supports memory and redis+elasticsearch. Realtime API
> <https://developers.google.com/drive/realtime/reference/> is also
> implemented here.
>
> So far, there has no editor integration, and doesn't contain any ui-related
> code, but will.
> Benefit from the distributed publish/subscribe event bus across
> server/browser/iOS/Android and no ui specific code, it is easy to implement
> client libraries on multiple platforms.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message