3 ms·

My opinion of where Wave went wrong is that it was completely non-extensible past a couple of fairly limited extension points. You couldn't build brand new real

My opinion of where Wave went wrong is that it was completely non-extensible past a couple of fairly limited extension points. You couldn't build brand new real-time applications on top of Wave. What they should've done was simply expose their real-time technology stack, then let people create documents backed by whatever (sandboxed) Javascript they want. When you open a wave, the Wave client would download the relevant Javascript, then use that to generate the user interface for the document, while managing the complexities of operational transforms and federation itself.

aidos 13y ago
I thought the server was open source running a documented protocol? I never got to close to it other than playing with the client. I recall considering installing the server - May be misremembering though....
- vertex-four 13y ago
  The issue is that the protocol pretty much only let people implement feature-for-feature compatible Wave servers. It wouldn't be possible to extend it past that.
- Jtsummers 13y ago
  There were two protocols. One used internally by the Google Wave server, and a federation protocol based on XMPP. Extending waves could be done with gadgets and bots. Bots were essentially XMPP clients that could observe the wave and submit changes to it [1]. Gadgets had other utilities, like introducing features to a wave document. I can't remember any particularly interesting ones, but some simple ones would be dice rollers and polls. [1] I played with a clojure REPL bot at one point, neat concept and I liked the idea for a collaborative way to teach someone how to program or pair program. I toyed for a time with exposing a common lisp REPL (I didn't get far) to create a collaborative worksheet-style interface. Since the underlying technology was language agnostic I thought it would have been neat as a way to integrate a number of different interactive languages.
ianbicking 13y ago
Like https://developers.google.com/drive/realtime/ https://developers.google.com/drive/realtime/ ? (Except the Realtime API doesn't really do anything about embedding realtime components in a compound document)
- vertex-four 13y ago
  Yes, pretty much, but that'd have to be combined with some sort of "sharing", "inbox" and/or "following" system like Wave came with. Perhaps email could be hacked into being that, but then we have the issue of "what happens when the service provider goes down" - Drive Realtime doesn't provide automatic saving of the Javascript that I can view and edit my document with, likely ending up relying on a third-party not to go down. I suspect that it'd be "easy" to build an MVP of what I suggest on top of Google Drive and Google Drive Realtime, or even on top of some of Wave's internals.
darkflame 13y ago
"You couldn't build brand new real-time applications on top of Wave." Not true; arwave.org (see vids) Sadly on hold till apache gets a client protocal

aidos 13y ago

I thought the server was open source running a documented protocol? I never got to close to it other than playing with the client. I recall considering installing the server - May be misremembering though....

vertex-four 13y ago
The issue is that the protocol pretty much only let people implement feature-for-feature compatible Wave servers. It wouldn't be possible to extend it past that.
Jtsummers 13y ago
There were two protocols. One used internally by the Google Wave server, and a federation protocol based on XMPP. Extending waves could be done with gadgets and bots. Bots were essentially XMPP clients that could observe the wave and submit changes to it [1]. Gadgets had other utilities, like introducing features to a wave document. I can't remember any particularly interesting ones, but some simple ones would be dice rollers and polls. [1] I played with a clojure REPL bot at one point, neat concept and I liked the idea for a collaborative way to teach someone how to program or pair program. I toyed for a time with exposing a common lisp REPL (I didn't get far) to create a collaborative worksheet-style interface. Since the underlying technology was language agnostic I thought it would have been neat as a way to integrate a number of different interactive languages.

ianbicking 13y ago

Like https://developers.google.com/drive/realtime/ https://developers.google.com/drive/realtime/ ? (Except the Realtime API doesn't really do anything about embedding realtime components in a compound document)

vertex-four 13y ago
Yes, pretty much, but that'd have to be combined with some sort of "sharing", "inbox" and/or "following" system like Wave came with. Perhaps email could be hacked into being that, but then we have the issue of "what happens when the service provider goes down" - Drive Realtime doesn't provide automatic saving of the Javascript that I can view and edit my document with, likely ending up relying on a third-party not to go down. I suspect that it'd be "easy" to build an MVP of what I suggest on top of Google Drive and Google Drive Realtime, or even on top of some of Wave's internals.

darkflame 13y ago

"You couldn't build brand new real-time applications on top of Wave." Not true; arwave.org (see vids) Sadly on hold till apache gets a client protocal