Ask Slashdot: Best Way To Implement Wave Protocol Self Hosted? 112
First time accepted submitter zeigerpuppy writes "It's time to revisit Wave, or is it? I have been looking to implement a Wave installation on my server for private group collaboration. However, all evolutions of Wave seem to be closed-source or experiencing minimal development. I was excited about Kune, but its development looks stalled and despite Rizzoma claiming to be Open-Source, their code is nowhere to be found! Wave-in-a-box looks dead. So Slashdotters, do any of you have a working self-hosted Wave implementation?"
I'm 40 and what is this? (Score:5, Interesting)
I remember Wave being one of those beta services Google killed off and people make fun off, but that's all I knew.
So I followed the link to Wikipedia, and it's a horrible stub that doesn't even define, let alone explain.
So some geek is trying to find someone else's implementation of an abandoned Internet protocol to build on top of?
But there's no explanation anywhere about why anybody would want to use this.
Re: (Score:1)
what is wave.
Re: (Score:1, Funny)
baby don't hurt me?
Re: (Score:1)
ISWYDT - c'mon moddy people - this is FUNNY (Score:1)
ISWYDT - c'mon moddy people - this is FUNNY
Re:I'm 40 and what is this? (Score:5, Informative)
Your frustration in understanding what Wave is mirrors that of most people who tried to understand what Wave was at the time it was around. As someone who participated in one or two waves but never got that deep into it, let me see if I can explain it from my limited recollection.
Basically, it was like e-mail meets something like version control. Kinda. You'd start a "wave" just like you might start an e-mail, by adding recipients, a subject, and a message. And they'd all receive it just like they would an e-mail. But from there, things could fork (I can't remember what the actual term was, so I'm using "fork" since we should all understand what I mean by that) and you could get more waves forming from the first one. A common example people gave was running a D&D campaign as a wave. The main wave would be the campaign itself, but then you might fork whenever a question came up that you wanted to address with the DM privately, by forking off from a particular point and only inviting him to that wave. And you might run a parallel wave that was the table talk for the game that everyone participated in. They'd all still be tied back to the original wave, but it organized them in such a way that you could jump between them relatively easily and keep track of everything.
Again, that's all based on my limited recollection, so I'm likely off on some of that, but I'm sure someone else can correct any mistakes I made.
TL;DR: it was one of those things you just had to use, since it made no sense and had no appeal at all on paper, but in actual use, it seemed like the sort of thing that actually could serve people fairly well, assuming they ever figured out how to explain it in a way that made sense...which never happened.
Re: I'm 40 and what is this? (Score:2)
My biggest issue was wave was the real time aspect. I do t want my draft replies to be visible as I type them.
Also, gmail search didn't hit it, which was a pain, but I'll assume beta related.
In concept, easy to make multi-featured discussion boards was great I thought.
Re: (Score:2)
I do t want my draft replies to be visible as I type them.
Why ever no t? What could passably go wrong?
:-)
Re: (Score:3)
Basically, it was a wiki with access control and live updates. But most people were not comfortable with the fact that they might miss a change somewhere within the page, so most waves I followed had rules posted at the top that basically said "add your comments at the bottom", making it look more like a facebook comments feed.
Re: (Score:2)
It was less about e-mail and more about a document.
Basically think of starting a document (or more like a OneNote/EverNote notebook), sharing it with people, and everyone editing it at once (everyone can see every else's changes in real time). There were also plug-ins for embedding objects such as maps and video.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Which rather than answering the question makes it even more of a good question.
Given that the live editing in drive is "from wave" what does wave offer that drive does not?
Re: (Score:1)
i guess the main features was an open, distributed protocol (like xmpp) where everyone could set up a server.. try that with a google docs.. .. except that part that it was supposed to have an openly documented protocol..
in addition i think it allowed adding much more "rich" widgets with their own set of features.. so i guess you could get wave as a combination of google drive (real time editing) and google hangouts (various real time widgets)
Re: (Score:2)
Re:I'm 40 and what is this? (Score:5, Informative)
Wave was marketed as a successor to e-mail, but (1) that just confused everyone (because what does "successor to e-mail" even mean) and (2) in my experience that was not a good way to view it.
A simpler way to view Wave was as a federated form of Google Docs with added support for threaded conversations in the style of e-mail threads or chat logs.
If we want to break it down, Wave is/was a federated, personal, realtime, wysiwyg wiki with strong support for threaded conversations, sharing, history, and privacy and access controls. This combination of features means that wave can be used for a wide variety of communications from chat to e-mail to blogging to collaborative document writing.
Wiki: I'm going to assume you are already familiar with the "Wiki Way". Basically a "wave" document is a wiki page that you create and can freely edit.
Threaded: While wave allowed multiple users to edit document as holistic entities, it also supported structuring documents as a mailing-list style tree structure of threaded replies. Private side conversations not visible to the entire group were also supported.
Realtime: Perhaps the most important feature of Wave was that your edits were instantly viewable. If you and a friend make successive edits, it can be used as a chat system. (Wave had support to make this easy and so each additional edit could be appended at the end.)
Personal: The wiki documents that you create exist in their own private namespace (e.g. just like documents on different webservers) and usually (always?) are just internal identifiers not intended for to directly manipulate. This avoids the problem that standard wikis have of dealing with contention for document names.
Sharing: You could send a "wave" document to another user and have it appear in their inbox. You could also invite others to participate in an existing wave. Your inbox would also be notified when a wave that you were watching was updated (e.g. like how you receive a reply to an e-mail).
Privacy: Wave documents are by default not publicly visible and have sophisticated and easy to use access controls.
WYSIWYG: User's edit their documents as they would in any modern word processor or e-mail client without having to know about any sort of wiki syntax.
History: Like any good wiki, wave supported viewing older versions of a document.
Federated: I can run a wave server and you can run a wave server and both of them can interoperate. This is similar to how different companies can run different e-mail servers and unlike private communication systems like Facebook messaging. For people who want to maintain a free internet, this is an important feature. However, unlike e-mail, the authoritative copy of the document stays on the creators host. Though there is support for caching, I never clearly understood where wave fell on the problem of hosts lying and trying to rewrite history.
In the end, Wave was a good product that was marketed poorly (the marketing explanations left people not knowing what it was). The efforts to make it federated required the creation of a public spec which also probably slowed down development.
I think Wave was an awesome idea and others should build on its concepts, but shouldn't tie themselves to how those ideas were implemented in wave. In particular, the rise of Facebook may have changed what people expect from their communication platforms so some of Wave's ideas may need to be updated to encompas that. (I don't use Facebook so I don't know what those changes would be.) But if the next social platform were to support Wave-like ideas, then it could be very nicely positioned as a Facebook-killer as it could represent a next-generation advance in social platforms.
Re: (Score:1)
Re: (Score:1)
Why Wave? (Score:2)
How about tickling your fancy with email and a federated social network such as http://buddycloud.com/ [buddycloud.com] and good old email?
Re: Why Wave? (Score:5, Funny)
It's the perfect geek social network
No one uses it
Re:Why Wave? (Score:4, Interesting)
Re: (Score:1)
if it's for corporate purposes just use share point.
blech (Score:1)
Isn't sharepoint a microsoft product? why touch that crap? he would have to install a *gulp* windows "server" for it.
Re: blech (Score:2)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
And some of it's ideas in ownCloud 6 : operational transform collaborative editing available for OpenDocument in the browser.
Re: (Score:2)
It's not even good for that. Using Wiki for an internal documentation system is infinitely superior despite lacking WYSIWYG editting and drag-and-drop functionality. At least you have a built-in and obvious revision control system using Wiki. Wave just makes everything look like a mess. Not to mention, Wave-in-a-box is broken all over the place in its current state. Any of the killer features, like integrating various Google features like maps, etc just isn't there.
You're far better off using something
Re: (Score:1)
My company likes WYSIWYG. Wiki is fairly arcane and training users on it can be a royal PITA.
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Reason to switch? What does this provide that I don't have now? It wasn't immediately clear when I read the blurb. For example: 802.11s provides a mesh network. It can be a globally connected internet beyond government control. You could --in theory-- have a network travelling hundreds or thousands of miles that never touches the traditional internet. What is the transport medium of Wave? Is it medium independent? Is it like sneakernet or RfC 1149 (IP over avian carrier)? It is never mentioned in t
Re:Why Wave? (Score:5, Informative)
1) between servers, Wave federation uses XMPP with some mumbo-jumbo/magic messages and as such it can be hosted (and interconnected) in a mesh, so yes it is medium independent.
2) between server and client Wave uses HTTP with websocket.
3) Wave is not a moving target as the protocol is no longer developed at high pace, if at all. The "Wave in a box" platform is still being incubated by Apache (waiting to get stable an attract developers).
4) I personally participated to the beta and I liked it.The potential to couple cooperative editing with the replay feature is huge on a lot of use-cases. It just gave you too many tools editing and little automated housekeeping so it ended a lot messier than e-mail conversations. Also, Google version of Wave was awful as a workflow. Rizzoma looks way better.
Re: (Score:2)
Re: (Score:2)
Because it wanted to replace e-mail it tried the federated approach for inter-server communication. Having servers of different ownership communicate freely would have provided migration or further along the way interconnection with social media (think about migrating a F
Re: (Score:2)
Re:Why Wave? (Score:4, Interesting)
For me it was never trying to be a social network. Wave was a great blend between chat, email, and forums which was phenomenal for collaboration on projects.
Unfortunately I never used it beyond that. It was way too bulky as a replacement for random chat, never had the features to properly replace forums, and we're pretty much stuck with email now so no point in trying to replace that.
Re: (Score:2)
That's Catch-22. Catch-21 was a gameshow where people played blackjack.
Catch-21? (Score:2)
WTF is a Catch-21? I know what a Catch-22 is seeing as how I worked for Captain Major before he was promoted to Major Major but again what is a Catch-21.
JSON (Score:1)
The WAVE implementation was heavily inter-twined with XML. Wave was introduced about the time everyone discovered that XML was more hassle than it was worth on the front-end
Re:JSON (Score:5, Insightful)
"Oh no, they used one really bad verbose text based encoding, rather than another really bad verbose text based encoding that I happen to like because it's cool these days, both of which have decoding support in the browser. This is clearly what will stop it from ever working properly"
Re: (Score:2)
It might stop egoistic developers from working on it.
Re: (Score:2)
JSON is verbose? That's news to me. Make it any more dense and it becomes hard to read for humans - and having human readable messages is one thing I don't want to give up, speaking as a developer. I don't want binary messaging. It has been tried. (It doesn't prevent anyone from sending natively binary data - as opposed to data that is made binary but might as well just be text - in another way, but for a lot of communication it's great.)
Re: (Score:2)
JSON is fine for sending a single record, but fails hard when you want to send 1,000s of records, since it sends the contract with every single record. This is made even worse by including lengthy, descriptive field names e.g.
{
CustomerId : "ABCDEF012938487432112424242322426",
AllowExtendedConfiguation: "true",
IsMaximumLengthRequired : "true"
}
Sending 1,000 copies of that is going to take a lot more packets than a fixed binary format where you can pack the entire th
Re: (Score:2)
JSON is fine for sending a single record, but fails hard when you want to send 1,000s of records, since it sends the contract with every single record.
Can't you include the field names once, followed by the records as arrays?
{
"fields" : [ "CustomerId", "AllowExtendedConfiguration", "IsMaximumLengthRequired" ]
"records" : [
[ "ABCDEF012938487432112424242322426", "true", "true" ],
[ "GHIJKLMN3458745092349837469089845", "false", "true" ]
]
}
Then rebuild your object
Re: (Score:2)
At that point, you're simply sending really verbose CSV.
Re: (Score:2)
And what would be wrong with that?
Re: (Score:2)
Given that the above commenter was trying to establish that JSON was not overly verbose, and even his example of how to combat the overly verboseness is overly verbose, what's wrong is that it doesn't back up the argument that JSON isn't overly verbose.
Re: (Score:2)
If you're doing it like that you might as well just send a CSV file instead or something similar, rather than shoehorning that into a JSON document.
Re: (Score:2)
It's tragic how this is always being rediscovered...
back in the late 80's I wrote software that sent wire data for financial transactions... it was not open source, it was proprietary and sold as part of my company's product portfolio for wall street.
However, we did exactly this.. all client's taking part in the transactions first spent a few minutes (back then!) loading the data dictionary. Subsequent information packets were packed binary data with each field having a dictionary ID. There were 1 byte INT
Re: (Score:2)
First, thanks for ignoring the solution given to the problem mentioned - use common sense, and arrays.
Second, the data that goes over the wire *IS* binary - it is (de)compressed on the fly.
Third, the majority prefers human readable formats. That's why those formats became popular - "popular": "liked or admired by many people or by a particular person or group".
(Forgot this) (Score:2)
Fourth, use common sense.
Don't even try to come up with extreme cases where something else obviously does make more sense then these text formats. Because also obviously there is no one-size-fits-all. So if you think you have a problem that is better solved using some other format, binary, whatever, just DO it and don't try to use your particular example as "counter point" why everything else is wrong.
Re:JSON, binary wire protocols and ZIP (Score:2)
There were 1 byte INTs, 2 byte INTs, 3 byte INTs and 4 byte INTs, variable length strings, booleans packed into bit fields, etc. It was very wire efficient, and this was because back then the wires were really slow. We had utilities developed to view the wire data and corelate it with the data dictionary, so we could inspect and debug captured wire data.
I feel you. Those wires were slow.
In the 90s I was toying with the ASN.1 spec [wikipedia.org] and its many derivatives, trying to find a good balance between a wire-stream and random access storage protocol. It would consist of a series of synchronous streams transmitted in tandem with shifting, the most primitive being the raw ASN.1 transmittal of data, each successive meta-stream on top of it consisting of lisp-like primitives that act on the data and 'unroll' it into more symbolic form, providing entry vectors for tr
Re: (Score:2)
Sending 1,000 copies of that is going to take a lot more packets than a fixed binary format where you can pack the entire thing down to 9 bytes e.g. 8 bytes for the Id, and both bools into a bitset on the last byte.
That's why you compress the stream. HTTP supports Content-Encoding: gzip, or you can wrap it around your file format on disk. Here's what happens with your example:
user@host:~$ ruby <<EOF | gzip | wc -c
prng = Random.new
1000.times do |i|
puts <<EOR
{
CustomerId: "#{prng.bytes(8).unpack('H*').first}",
AllowExtendedConfiguation: "#{prng.rand(2).zero? ? 'true' : 'false'}",
IsMaximumLengthRequired: "#{prng.rand(2).zero? ? 'true' : 'false'}"
},
EOR
end
EOF
12550
12550 bytes... 12.5 bytes per record, instead of your hand-optimized 9 bytes per record. I'm only paying a 28% premium with 100% random data. When it contains text strings (and we're talking about Wave here - it's mostly text) it's quite common for gzipped JSON to be smaller than an optimized but uncompressed binary format.
This frequently ha
Re: (Score:2)
That's a pretty solid example you're provided there. There's a small issue with you using a truncated customerId, since you're assuming it's an autoincrement variable, and those are going out of fashion now we're having to build for clustered installations. If you're using MongoDB it will be comprised of a serverId, a snapshot of the current time, and a random portion. For a single DB solution, your example is fine.
You could try compressing the binary data, there's no reason that stream can't be compressed
Re: (Score:2)
It doesn't require all those extras brackets and braces and quotes.
My point is all those extra brackets, braces, and quotes (and field labels) don't cost you much. They compress efficiently.
JSON is like any hammer. Sometimes you gotta know when it's time to put it down and pick up the screwdriver instead.
No argument there - JSON isn't my only tool. :) I just disagree that it "fails hard when you want to send 1,000s of records".
Re: (Score:2)
If you're talking customer numbers, not customer serials (as used above) for your optimised case, then the binary case too can be more heavily optimised. Byte 1 encodes 2 bits for the two flags, then 6 bits for the number of bytes the customer ID takes up (as an integer, not a string). This gives you 2 bytes for your first 256 customers, 3 for your next 65280, and 4 for your next 16711680. For most companies that means you're likely to be averaging 3.5 bytes per record, suddenly we've compressed our wire
Re: (Score:2)
{
CustomerId : "ABCDEF012938487432112424242322426",
AllowExtendedConfiguation: "true",
IsMaximumLengthRequired : "true"
}
This is not valid JSON : keys must be encoded.
And it it inefficient to send boolean values as strings instead of booleans because that data type is fully supported in JSON [json.org].
{
"CustomerId": "ABCDEF012938487432112424242322426",
"AllowExtendedConfiguation": true,
"IsMaximumLengthRequired": true
}
Re: (Score:2)
This is not valid JSON : keys must be encoded.
s/encoded/quoted/
Re: (Score:2)
So my example should have actually been 6 characters more verbose than it was ;p
Re:JSON (Score:4, Insightful)
Most of the complaints I hear about XML are really complaints about lousy software architecture. Yes, XML is complex, but that should cause *zero* hassle on the front end. If it is causing hassle throughout your project, you're doing something wrong architecturally.
The desire to flex your muscles in a hot technology often overwhelms good design sense. Thus ten years ago you'd see people parsing and doing XML DOM tree manipulation directly in UI code and crap like that. Doing the same with JSON would be just as bad design, although since JSON's feature set is much smaller the results are less immediately catastrophic. But they're still bad design.
If your objection to XML is that it spreads complexity throughout your code, you're just a mediocre coder. Choosing XML or JSON should be a very minor implementation detail.
Re: (Score:3)
I'm not saying that it makes no difference. I'm saying it's an implementation detail, which is a far cry from saying the choice never matters. If you can't grasp the distinction between a choice mattering and it needing to be localized in a design, you'll never be a competent software designer.
If a system is somehow irretrievably ruined by choosing XML over JSON, then bad programming must be at least equally to blame because if you don't need any XML features that JSON doesn't have, the switch should be ea
Re: (Score:2)
The difference I was originally highlighting was more that Wave integrated with XML at the server, in a season that people realized the implications of "AJAX" (i.e. JSON)
Well, seems like apples and oranges to me. AJAX is not a data representation model, it's a communication model. If you have to, say, obtain data from a server to repopulate an HTML table in response to a user action, JSON fits the bill, because you need only the most rudimentary semantics. But that doesn't mean JSON can replace XML for every purpose, e.g. something like Open Document Format. So you might well do a lot of AJAXy stuff with JSON to the browser, but do a lot of DOM manipulation stuff on the ser
Re: (Score:2)
Text vs. binary protocols is an interesting discussion. I've designed several protocols, and we have this debate every time. It turns out in practice that binary protocols designed for 'efficiency' aren't more compact than XML on the wire (or JSON), because that kind of repetitive text compresses extremely well, so while it's human readable "inefficient" text at the endpoints where people can see it, it's quite efficient packed binary on the wire where it costs money to move the data. So the text format, in
wave is not dead, just a little slow in incubation (Score:4, Informative)
due to low numbers of people working on the project.. but here's an idea.. GET INVOLVED. https://incubator.apache.org/wave/get-involved.html [apache.org]
Re: (Score:1)
Really? (Score:1, Informative)
and despite Rizzoma claiming to be Open-Source, their code is nowhere to be found!
Funny, I found it in 5 seconds here [github.com] after simply doing a search for "Rizzoma source code".
Re:Really? (Score:5, Informative)
There are no updates on Rizzoma core since early this year (I think January) and they didn't choose a license for it.
I saw that they are still working on some gadgets, and their server performs quite well, but that is a sign that developer involvement decreased once they reached a stable base.
Re: (Score:1)
Re: (Score:1)
The Wave Story (Score:4, Informative)
Here's what happened in excruciating detail:
1) Google Releases Wave, claims it will be open source. Promises/Tells a Fibonacci.
2) Google doesn't release Wave as open source for various reasons eg: protocol buffers toolchain underneath deemed too valuable. (Please don't argue this, the protocol buffers stuff that's been released is only a tiny part of the story.)
3) Google builds a terrible open source replacement pretty much from scratch. It BARELY works for one commit nearly 3 years after they claim Wave will be open sourced. It never has been. Entire affair is swept under carpet.
I know because I had an ehealth startup [tricorder.org] that died partially as a result of this. In the end, after we realized we had been hoodwinked (this post excludes private conversations we had with Google) we wrote a Wave-like thing around part of our technology in record time and it surprisingly turned out really well, but unfortunately it was too late, and company died. That was sad. Startups are fragile things.
Anyhow, try sharejs [sharejs.org] it's written by a former Wave team member and it's better. You can easily wrap gwt around that if you need to. Or, I'm highly skeptical but you can try JBoss Errai [erraiframework.org], they have written an OT framework into their weird everything framework. OT is a pretty complicated bit of code, and they just stuck it in a directory errai-otec [github.com] like it was any other feature (eg. a Base64 encoder). I would rate the chance their OT impl has major issues as very high. I don't really understand corporate open source like this, so I'd love to see an Errai person explain the project. I'm guessing the thesis is somehow based around upselling a service of some sort.
tl;dr You want this. [sharejs.org]
Support A Free Internet [uplink.aero]
Re: (Score:2)
Shrug. So I have a higher risk tolerance than you. Everyone is different. If you don't understand or believe that startups/companies are a bundle of bets on many different factors that you can't control then you don't understand startups. I think you need to have more exits than me if you are going to criticize my business sense, Mr. Armchair Quarterback. Also the company ultimately died because on of the investors was bright enough to knock back an offer of investment. That person wasn't me.
Also we trusted
Re: (Score:1)
I've been a part of three startups. Two sold for profits, one for 100M+, one for 200M+. I'm working for the third startup now. I wouldn't even consider working for or investing in one like that. It would be one thing if it was already open source, or if it had sufficient uptake to make no financial sense for Google to shut off. You don't bet on something that far out of your control- you're better off going to a casino with your money. Its practically entrepenurship 101.
There are smart risks and dumb
Re: (Score:2)
Part of 3 startups. So you've worked in Silicon Valley. Good for you. If you are some amazing founder/investor, instead of a know-it-all software engineer, please do post your personal links so I can learn more.
BTW The Wave stuff was only a small component of our value offering. So your supposition that we "built a startup around a protocol that wasn't yet released, that wasn't well documented, that wasn't in your control" is just wrong. That's why I said "partially". There were other contributing factors.
Re: (Score:2)
I've been a part of three startups. Two sold for profits, one for 100M+, one for 200M+
If you were as "involved" as the GP poster was and your startups sold for 100+ and 200+M, then you should be making this post from yout yacht.
You don't bet on something that far out of your control- you're better off going to a casino with your money. Its practically entrepenurship 101.
something tells me you've never founded a startup. At that point, basically almost everything is completely out of your control and you ha
Re: (Score:2)
One of the ways that startups beat the bigger companies is that they take risks that larger organizations wouldn't. If his company bet that Google Wave would give them a huge edge in the market, and jumping on the platform very early could help them break out, that's the sort of decision that startups do all the time. Remember, if they engineered the way big companies typically do, they wouldn't be able to beat the big companies, because it'd be slow,expensive and risk averse. So startups take crazy risks,
Re: (Score:1)
Re: (Score:2)
Just heard about this: https://github.com/WeTheInternet/collide [github.com] - thought you might be interested.
Re: (Score:1)
Out of curiosity (Score:2)
Re: (Score:1)
The best place to ask is... (Score:2)
...Google Plus.
I liked it (Score:2)
I liked Google Wave, it was good for the sort of collaboration work I do quite often - working on specification documents. Better than a live document. I was annoyed when they killed it off as I was just starting to see more use for it.
Re: (Score:1)
Product Placement (Score:2)
If Google Wave was featured in a movie, it would be directed by John Romero and people would be trying to kill it with a shotgun.
Re: (Score:2)
I thought they already dropped support for it a while back........
i just wasn't aware that someone had been using it for something!
Re: (Score:1)