Ask Slashdot: Best Way To Implement Wave Protocol Self Hosted?

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?"

Comments

not dead

[Anonymous Coward]

wave in a box isn't dead. slow progress but still progress is happening in the apache wave comunity... for what i know, wiab works as of now with a minimal sets of features

Re:not dead

[zeigerpuppy]

Sorry, didn't mean to announce a premature demise, I must admit that I was hoping that wave in a box would be a little more mature by now. (although I have no right to complain, not having contributed any code myself!). As a side note, I guess this is the best spot to try out the code: https://github.com/apache/wave

Unh!

[Anonymous Coward]

Wave goodbye

Why Wave?

[thatkid_2002]

Who else uses it? I know this is a catch-21 sort of thing. I don't see what Wave really offers over social networks (in conjunction with good old email).
How about tickling your fancy with email and a federated social network such as http://buddycloud.com/ and good old email?

Re: Why Wave?

[alen]

It's the perfect geek social network
No one uses it

Re:Why Wave?

[gmuslera]

Don't think on it as a worldwide, new social network, but for deploying it as a collaboration/documentation platform inside a company. In that area could be pretty useful.

Re:Why Wave?

[Anonymous Coward]

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 the blurb. Another kicker to adoption is the fact that the protocol is not finished yet. It might be easier to code to a target, once the target stops moving.

Re: Why Wave?

[Anonymous Coward]

"Don't you know the places we can go with this?"
"Yeah, I do. There's nobody there."
"Exactly."

--Sneakers (1992)

Re:Why Wave?

[PhrostyMcByte]

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:Why Wave?

[noh8rz10]

if it's for corporate purposes just use share point.

Re:Why Wave?

[mitzampt]

Just to solve some of the unknowns of the thread:
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:Why Wave?

[JamesRing]

I think the core of it lives on in products like Google Docs and Spreadsheets.

Re:Why Wave?

[Jethro]

That's Catch-22. Catch-21 was a gameshow where people played blackjack.

Re:Why Wave?

[afxgrin]

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 like Sharepoint or OpenGroupware to manage corporate comms and the Wiki for documentation.

Re:Why Wave?

[hodagacz]

My company likes WYSIWYG. Wiki is fairly arcane and training users on it can be a royal PITA.

Re:Why Wave?

[Dr_Barnowl]

And some of it's ideas in ownCloud 6 : operational transform collaborative editing available for OpenDocument in the browser.

Re:Why Wave?

[Anonymous Coward]

Oh god. Corporate social networking (tripartite oxymoron?) and document repository. These exist.

Posting anonymously, just in case. We use Jive. Amazingly their "community" platform powers forums used by lots of the big players - I've spotted it being used by Apple, Adobe, BMC, Redhat, Oracle.... not IBM or Microsoft, who have competing products, but it's a big player.

And you can enable gamification... don't get me started.

Re: Why Wave?

[Anonymous Coward]

I'm shocked people aren't jumping all over the Sneakers references with NSA in the news... it's one of the few technology based movies that's stayed relevant over 20 years.

Re:Why Wave?

[thatkid_2002]

Yes of course - but why Wave over tools provided in a modern social network? Technologically BuddyCloud is similar - and BuddyCloud has protocols documented, and because of their modular nature they don't represent a moving target.

Re:Why Wave?

[Anonymous Coward]

You're far better off using something like Sharepoint

Wow. Is wave really that bad???

Re:Why Wave?

[mitzampt]

I think I went on with the Google hype about Wave, but I could see in it a replacement for current usage of e-mail (document collaboration, discussion threads, file transfer) as a lot of people abuse the reply with history feature of mail.
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 Facebook group or a forum thread to a Wave conversation).
Also today we use a mix of realtime/instant (chat) and offline/persistent (e-mail) communication. Isn't it time that somebody would try to invent a product offering both types of communication in the same package?

Re:Why Wave?

[zeigerpuppy]

That's exactly right, I like Wave because it makes the discussion to documentation progression relatively seamless. Other alternatives tent to fall down on either privacy or not being free software.

Re:Why Wave?

[zeigerpuppy]

That's true, my users are relatively computer illiterate. They don't want to learn syntax as much as I do.

Re:Why Wave?

[thatkid_2002]

XMPP is what made this happen... BuddyCloud does this ;)

JSON

[Anonymous Coward]

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

[beelsebob]

"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:JSON

[bill_mcgonigle]

It might stop egoistic developers from working on it.

Re:JSON

[Anonymous Coward]

Everybody wins!

Re:JSON

[hey!]

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:JSON

[Anonymous Coward]

processing text aganinst binary coding (not sure wave is that) makes a hell of a difference for some applications. Chosing xml may not be such a minor detail as you propose. Could this be that you are a good coder and still have no clue?

Re:JSON

[hey!]

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

Re:JSON

[mha]

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:JSON

[Anonymous Coward]

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)

So why conform to Google's elaborate XML synthesis at the server when all could easily be accomplished with light-weight JavaScript calls. It was just poor timing for Google, since all the "magic" of Wave was more or less AJAX: and its beta was about when most people realized the interactivity of the web could be realized without any of the Wave protocol overhead.

Re:JSON

[BlackHawk-666]

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 thing down to 9 bytes e.g. 8 bytes for the Id, and both bools into a bitset on the last byte.

JSON is definitely verbose in any case resembling that. YMMV.

Re:JSON

[wonkey_monkey]

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 on the other side.

Re:JSON

[hey!]

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

Not every tool has to work equally well for every task.

Re: JSON

[Anonymous Coward]

Only if you stop and think about how to solve the problem intelligently.

Re:JSON

[Inigo Montoya]

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

Today, in software and in networking applications, things like XML (good god! ), JSON (much better) and other open source wire formats become bloated because the developers want it all human readable and become complacent when they all have 8 core CPUs, 16GB memory and fiber to their desktops.

The wire format never needs to be human readable.

Now, get off my lawn :)

Re: JSON

[Anonymous Coward]

XML is like violence. If it doesn't solve your problem you need to use more.

Re:JSON

[mha]

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

Re:JSON

[subreality]

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 happens even with raw numbers. You won't have 4 billion customers for a while, so let's make the first four bytes of the CustomerId all zeroes:

CustomerId: "00000000#{prng.bytes(4).unpack('H*').first}",

I now have 7.5 bytes per record. I'm already doing better than your binary format, unless you plan to do variable length encoding on the customer ID. That'd be even more code you have to write and debug.

There are certainly cases where shaving off the last few bytes might be worthwhile, but for the general internet, and for the kind of uses that Wave is meant for... no. The simpler code (not inventing a new serialization format) and debugging advantages of human-readable streams outweigh the marginal bandwidth savings of a binary protocol.

Re:JSON

[dolmen.fr]

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

{
        "CustomerId": "ABCDEF012938487432112424242322426",
        "AllowExtendedConfiguation": true,
        "IsMaximumLengthRequired": true
}

Re:JSON

[dolmen.fr]

This is not valid JSON : keys must be encoded.

s/encoded/quoted/

Re:JSON

[laird]

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 addition to being easier to implement, and easier to maintain, because you can leverage all of the work that's gone into parsers, schema definitions, existing standards (e.g. SOAP, REST) and data types,etc., while binary formats tend to be re-invented every time, and make the same mistakes over and over. By using SOAP (for example) you get headers, protocol versioning, data structures, message validation, etc., all done, so you just have to define your specific messaging, and bolt in a standard SOAP messaging library.

Re:JSON

[Anonymous Coward]

Can't you include the field names once, followed by the records as arrays?

Yes, you most certainly can.

Then rebuild your object on the other side.

Spot on. That's what we do at my company, for bulkier data transfers. Works very well.

(One example is long sequences of historic quote data, commonly spanning quite a few years. A structure as in your example combined with automatic compression in the hardware load-balancer results in a compact-enough payload that is still fairly easy to debug when viewed by a human.)

Re:JSON

[BlackHawk-666]

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:JSON

[BlackHawk-666]

So my example should have actually been 6 characters more verbose than it was ;p

Re:JSON

[BlackHawk-666]

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 by the servers on read / write. Most binary data can usually be compressed, with 50% being about average for the usual contents of a filesystem. I guess you'd get about 25% on that example, but really, anything would be gravy.

Finally, if you data really benefits from being text, and it is a simple column row array like that example, you might as well use a form of CSV e.g.

CustomerId,AllowExtendedConfiguation,IsMaximumLengthRequired
ABCDEF012938487432112424242322426,1,1
XHSGSJD12938487432112424242322426,1,1
OFIDKSA12938487432112424242322426,1,1

You can skip the quotes, skip over the padding that is just for the humans, use \n instead of \r\n and only need to escape commas if they occur in your text, which they won't for a lot of fields.

So now you have a human readable text representation that is more efficient that JSON, compresses just as well, and can be loaded into an editor (you surely don't use notepad, favoring notepad++ or another nor brainbead editor that can read unix formatted text files). It doesn't require all those extras brackets and braces and quotes.

JSON is like any hammer. Sometimes you gotta know when it's time to put it down and pick up the screwdriver instead.

Re:JSON

[beelsebob]

At that point, you're simply sending really verbose CSV.

Re:JSON

[Anonymous Coward]

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

JSON is definitely verbose in any case resembling that. YMMV.

So gzip it. Done. At least then you'd have a standard, portable, easy to work with format rather than yet another incompatible binary format.

Re:JSON

[subreality]

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:JSON

[wonkey_monkey]

And what would be wrong with that?

Re:JSON

[beelsebob]

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:JSON

[beelsebob]

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 format by more than 50%, and reduced the CPU overhead significantly as we no longer need to un-gzip the stream, then parse a bunch of text.

I'm 40 and what is this?

[Anonymous Coward]

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:I'm 40 and what is this?

[noh8rz10]

what is wave.

Re:I'm 40 and what is this?

[Anonymous Coward]

baby don't hurt me?

Re:I'm 40 and what is this?

[Anubis IV]

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?

[AvitarX]

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:I'm 40 and what is this?

[jrumney]

Basically, it was like e-mail meets something like version control.

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:I'm 40 and what is this?

[SQLGuru]

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: I'm 40 and what is this?

[grcumb]

I do t want my draft replies to be visible as I type them.

Why ever no t? What could passably go wrong?

:-)

Re:I'm 40 and what is this?

[demonlapin]

I used it with some friends as a shared space for discussing episodes of LOST while they were on. It was like private IRC with a shared document space. I liked it a lot, actually, except that its computational demands rapidly overpowered the netbooks we were running it on.

Re:I'm 40 and what is this?

[philip.paradis]

Don't hurt me, no more.

Re:I'm 40 and what is this?

[Chalnoth]

So, what does this offer that Docs in Google Drive doesn't?

Re:I'm 40 and what is this?

[Anonymous Coward]

Drive features of live editing were from wave, when Wave was killed off.

Re:I'm 40 and what is this?

[mdmkolbe]

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:I'm 40 and what is this?

[zeigerpuppy]

Basically, Google can't be trusted with my users' data.

Re:I'm 40 and what is this?

[zeigerpuppy]

A good summary of the strengths, thanks for laying out these issues for other readers. I really liked these aspects too. Although I think marketing was not why it got axed. I don't think a federated service fitted with google's philosophy on data, i.e. they want it all going through their serrvers.

Re:I'm 40 and what is this?

[nedlohs]

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:I'm 40 and what is this?

[hpoul]

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..
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) .. except that part that it was supposed to have an openly documented protocol..

wave is not dead, just a little slow in incubation

[Anonymous Coward]

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

I'm going to get modded up!

[Anonymous Coward]

Clicked two links, still no idea what "Wave" does.

What does Wave do?

Really?

[Desler]

and despite Rizzoma claiming to be Open-Source, their code is nowhere to be found!

Funny, I found it in 5 seconds here after simply doing a search for "Rizzoma source code".

Re:Really?

[mitzampt]

Pardon me, but if you look closer, in that github there isn't any Rizzoma server, just some gadgets.
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:Really?

[Anonymous Coward]

and despite Rizzoma claiming to be Open-Source, their code is nowhere to be found!

Funny, I found it in 5 seconds here after simply doing a search for "Rizzoma source code".

I think the correct repository is:

https://gitorious.org/kune

Re:Really?

[zeigerpuppy]

So is Rizzoma just a spinoff of Kune?

Re:Really?

[zeigerpuppy]

Yeah, it's not great they they are claiming open source and not providing code, let alone an installable version.

Re:When Will We Wave Bye Bye To Wave?

[gl4ss]

I thought they already dropped support for it a while back........

i just wasn't aware that someone had been using it for something!

blech

[skaag]

Isn't sharepoint a microsoft product? why touch that crap? he would have to install a *gulp* windows "server" for it.

Re: blech

[KageUrufu]

With 3 servers for a full proper installation, according to Microsoft

Re: blech

[Seraphim_72]

One server is enough - according to Microsoft. Thanks for playing though.

Re: blech

[Anonymous Coward]

The software vendors of the world pull this all of the time. Microsoft. CA. IBM.

Yes. There is no doubt that someone highly familiar with vendor software, including SharePoint, could install it on a single server. I have installed a CA stack on a single server and can vouch that such things are possible.

Should this ever be done in Production? No. Absolutely not. Perhaps as a Dev instance or possibly if budget is tight a Test instance but never in Production. This would count as 'asking for it'.

According to Microsoft. Have a closer look at their documentation. At a minimum you are looking at three servers. Web server, database, application.

http://technet.microsoft.com/en-us/library/cc262485.aspx

Installation Scenario: Single server with a built-in database or single server that uses SQL Server
Deployment type and scale: Development or evaluation installation of SharePoint Server 2013 or SharePoint Foundation 2013

Installation Scenario: Web server or application server in a three-tier farm
Deployment type and scale: Pilot, user acceptance test, or production deployment of SharePoint Server 2013 or SharePoint Foundation 2013.

Next time link to the official source and copy/paste from their docs. Thanks.

The Wave Story

[digitaltraveller]

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

Support A Free Internet

Re:The Wave Story

[digitaltraveller]

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 Google's word. Some of the API's (eg. the Robots API) got plenty of traction early on. We built a replacement. Like I said it wasn't the only contributing factor, but it didn't help. When a big company makes a promise like that - you expect them to follow through.

Re:The Wave Story

[AuMatar]

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 risks. Yours was a dumb risk.

Re:The Wave Story

[digitaltraveller]

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:The Wave Story

[Anonymous Coward]

Or not.
Does this person seem like they are moaning and groaning because (s)he now lives on the streets because of this failure?
No. This person sounds totally content with the results.
Some people can afford more than others; investing in 10 long shots may be profitable if each cost less than 10% of the potential winnings. Just one winner could pay off the losses of others (and maybe some of the other investments returned back something better than 0%).
We don't know what fallback strategy they had in mind. You're individual statements seem solid, but your general attitude seems overly harsh considering that we don't know many details.

Re:The Wave Story

[serviscope_minor]

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 have no idea what you're doing.

Re:The Wave Story

[zeigerpuppy]

Thanks for the suggestions, ShareJS looks really easy to integrate into a site that meets some of my needs.

Re:The Wave Story

[laird]

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, 90% fail, and the 10% do amazing things that the big guys are too timid to try. :-)

Re:The Wave Story

[Anonymous Coward]

It was a crap shoot to be 1st out of the gate with documented skills in a "new tech" from where I sit.

Yea, the gamble failed 'em. But its hard to be a low head count low funded startup without using others tech to bootstrap from.

Re:The Wave Story

[digitaltraveller]

Just heard about this: https://github.com/WeTheInternet/collide - thought you might be interested.

Re:The Wave Story

[zeigerpuppy]

Thanks, looks easy to install, will have to give it a whirl.

Out of curiosity

[multimediavt]

Zeigerpuppy...what features of Wave are missing from other open or closed source software do your collaborators need? I find it odd that you would go to a dead--or nearly dead--open source project based on a requirements/needs stage. Unless there is something that Wave does out of the box better than existing options that are in active development you are barking up the wrong tree. Plus, one of the advantages of Wave early on was that Google hosted it and collaboration across corporate lines made it attractive. If this is in-house collaboration, again, what is the reason for looking to Wave as a solution? You say "my server" and "private collaborations". If this is just something personal then why not just join the Wave dev group and contribute rather than fuss around?

Re:Out of curiosity

[zeigerpuppy]

The major features I am interested in are: real-time collaborative editing, discussion workflow and easy documentation/media integration. As the group's discussions are private, it needs to be self hosted. I prefer open source. Wave ticks the boxes. The closest I have found (and tried installing) is a version of etherpad. I was excited by Rizzoma as it looked like a more general purpose solution but doesn't look very open, unfortunately. I am more of a sysadmin than a developer and will certainly poke my head in to development of projects but I usually need something that has at least the minimal functionality out of the box for my users.

The best place to ask is...

[rs79]

...Google Plus.

Kune repository:

[Anonymous Coward]

took me two click's to find ...

https://gitorious.org/kune

I liked it

[jemmyw]

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:I liked it

[zeigerpuppy]

I never bought the "lack of uptake" angle that google pushed when they axed it. I think that a federated network is the opposite of what google wants. They want all the juicy bits passing through their servers and the federated model of wave was not good for this. I guess I at least need to thank them for opensourcing etherpad after they acquired that code.

Product Placement

[Ukab the Great]

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.

(Forgot this)

[mha]

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:wave is not dead, just a little slow in incubat

[zeigerpuppy]

a good suggestion, and I certainly wish the developers success with the continued project

Re:JSON, binary wire protocols and ZIP

[TheRealHocusLocus]

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 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 traversal and parsing.

Each lisp instruction block received would be compiled into pseudocode, but also a cryptographically strong hash produced from it that was also transmitted as part of the data stream, the hash becoming so 'synonymous' with the operation that it pseudocode could be applied repeatedly. The whole purpose was to create within a dataset a nested roll/unroll philosophy which could take table data that has extremely compressible rows for example, and serialize it in such a way that the result is 'half data', 'half instruction' where the more compressible the data the 'half instruction' starts to approach 100%.

Then I realized that I was trying to invent a general-purpose sentient form of the bzip aka Burrowsâ"Wheeler transform, and for most practical purposes the non-sentient form for streams would overtake my own efforts as memory and processor power increased.

So I relaxed a bit (with my new found feeling of innovative inadequacy) and did other things, while I waited for simple Burrowsâ"Wheeler transforms to make their way into the texty streamy side of things.

They never did, because in all but rare cases simple stream LZW gets close enough. But that didn't set t5he world on fire either, not at first. Even mod_deflate and mod_gzip support for the mostly-ASCII web loads of yesterday was slow in coming. I remember triumphantly implementing mod_deflate in my Apache server only to disable it because some IEs would miss end of stream marks and hang. Things are much better now.

ISWYDT - c'mon moddy people - this is FUNNY

[xxxJonBoyxxx]

ISWYDT - c'mon moddy people - this is FUNNY

Catch-21?

[AF_Cheddar_Head]

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.

Kune Source Code

[Anonymous Coward]

This did not take long to find.

http://ourproject.org/plugins/scmsvn/viewcvs.php/?root=kune

Re:Kune Source Code

[zeigerpuppy]

Just to clarify, Kune is very open with their code, it's Rizzoma who do not publish theirs, my article was a little unclear on this.