Google Wave “is anti-Web”
blogs.ft.com
blogs.ft.com
The services Wave aims to replace -- instant messengers, E-mail, IRC, groupware, Usenet -- are not part of the Web. While there are gateways between the Web and other Internet-based platforms, such as webmail and Mibbit, I'd guess that most interaction remains separate from the Web. Therefore, at worst, replacing these services with Wave is irrelevant to the status of the Web.
In a related note, Google itself has released Web gateways for E-mail and Usenet. I do not believe that they have since forgotten what the Web is. Indeed, Google's demonstration video itself demonstrates a Wave <-> Web gateway, in the form of an Javascript-based web application.
Second, Ozzie espouses an incorrect view of what Wave is. Based on the information Google has released so far, Wave is -- just like HTTP -- a protocol for communication between cooperating, heterogeneous agents. Aside from implementing Wave, which is merely a set of extensions to XMPP, no additional cooperation is required to write a Wave-enabled application. His statement that "Wave is just too big and complex a system" reveals just how fundamentally he fails to understand it.
Here, I take a quote and replace "Web" with "Wave":
"""As Ozzie described it, the power of Wave lies in the ability of many different developers to build their own, independent and interoperable implementations of services from toolkits of foundational technologies. It doesn’t matter if some of these implementations are very basic and lack the full capabilities of others: what matters is that they can be created easily and interoperate. """
Doesn't it remain true? Doesn't it still make sense?
I believe that Wave will be a roaring success, for the same reasons SMTP, NNTP and HTTP have been -- simple to implement, distributed, and not controlled by any single party.
I haven't looked into wave in much detail, but being based on XMPP is by no means simple. XMPP is the most over engineered over complex verbose ridiculous protocol ever invented. There were several people saying Jabber would kill IRC years ago.
I'm reserving judgement on wave personally, I'm skeptical it'll be able to make a dent. Technically awesome, but I'm not convinced yet it solves real problems users have.
Who?
I doubt anybody knowledgeable would claim that Jabber would kill IRC, since the two protocols serve largely different purposes. Jabber has killed off most of the smaller closed IM networks, and even the large ones are smaller than they once were.
As for the claimed difficulty of implementing XMPP, I'd like to see some more references on that. I'm writing an XMPP library now, and it doesn't seem particularly difficult. With only an hour or two of work, it can connect securely to 3rd-party servers and act as a useful bot. With a bit more work, I'm sure it could be a production-quality library.
Furthermore, the proliferation of implementations for various languages and platforms suggests that the barrier to entry for an XMPP library is rather low.
http://news.ycombinator.com/item?id=426581
Even the specs for XMPP+extensions seem to be written in XML, running to thousands of pages due to the overly-general-underly-practical nature.
I don't think expecting any modern protocol to support typing commands in by hand over netcat/telnet is reasonable.
$ openssl s_client -connect irc.mibbit.com:6697
In comparison, it's not possible to use a general tool to do anything like this with XMPP, because it's all wrapped in endless XML complexity.
Your example doesn't support TLS upgrading, forcing TLS and plaintext connections to be handled on separate ports. You also ignore authentication and authorization, which are much more important than merely opening an encrypted socket to some arbitrary server.
IRC is a nice protocol for things that don't matter, but it's utterly unsuitable for applications that require security or features beyond "send text and hope some client receives it, eventually".
I agree @TLS, authorization etc, but often those just aren't a priority.
email is often used without any security but it's far from something that "doesn't matter". IM protocols have barely any security, yet we all use them.
E-mail has optional security for things that do matter, namely GPG/PGP for client <-> client and the STARTTLS extension to SMTP for server <-> server. Wave, as a replacement for E-mail, provides pervasive security.
"IM protocols have barely any security" -- given that this discussion is regarding an IM protocol with a built-in high-quality security infrastructure, I don't see how this statement is at all valid.
I was talking about the main IM protocols in use today - yahoo/msn/aim.
You'd be surprised @ plain text. It quickly adds up. I do around 3.5TB of plain text IRC/http a month, and if I could reduce that, I would. If we were all using jabber instead of IRC my bandwidth would be more like 10TB. Quite a difference.
>> "E-mail has optional security for things that do matter, namely GPG/PGP for client <-> client and the STARTTLS extension to SMTP for server <-> server. Wave, as a replacement for E-mail, provides pervasive security."
That comes back to my original comment - I'm not sure it solves any real world problem users have. Users don't care about security like that.
I'm not sure that's accurate. Maybe users don't care about security, but I would venture that's because they don't know any better. I don't think most people understand that their emails and IMs are crossing the web in plaintext, or just how easy it would be for someone unintended to get access to those messages. I don't think it's an informed lack of concern.
Among other reasons, because the stream is invalid XML until ended, ruling out the use of 99% of XML libraries and leaving you writing your own crazy custom streaming parser.
The XML is without a doubt the worst thing about XMPP, IMO. The whole point of XML is that it is standardised, and yet until the last second of the stream the whole thing is invalid, ruling out all those standardised tools, removing the point, leaving a vacuum (which you then have to fill with tons of ridiculous reinvention of the wheel).
And don't even get me started on the ridiculous overuse of xml namespaces and the incredible fragmentation of the standard, which is in like 50 different parts. The entire format is an over-generalised, over-engineered, commitee-designed gordian knot of needless complexity, verbosity and just plain ugliness.
Why do you think there are so few XMPP implementations beyond a few mega-projects? Why should it be a mega-project at all? The XML foundation is a huge barrier to implementation and is the perfect example of counter-productive adoption of buzzword-of-the-day ideologies, handicapping a whole ecosystem for years afterwards.
As someone who has written the odd XMPP client I can only say: Amen, Hallejujah.
The idea and birdview architecture of Jabber is great. The execution is so horrible that most people who had the misfortune to work with it only want it to die ASAP.
Most of the problems stem from unfortunate timing. Jabber was invented in the late 90's when XML and Java engineering practices were hyped as the Next Big Thing™. Had it been invented only a few years earlier or later then we might not have anything to complain about today.
Well, my hopes are on google to end the insanity. They have plenty of skilled engineers working on wave. Once those engineers grow tired of the mess they might just go and replace it with something sane.
The big standout problem with XMPP is "XML streaming", which is fairly difficult to handle tersely, correctly, securely, and reliably. Mostly this is because parsing streaming XML (using, say, SAX) usually involves writing a lot of one-off code. Most of that code is just going to be making sure your messages correspond to the spec, don't start getting too deep, are complete, etc.
Then there's the out of band data stuff, which at the time, was basically undefined. Now, it's defined, in a whole lot of specs.
Then there's RTF, which is used by several Windows clients as a message format.
That's what I remember, at least, and skimming the current RFC's suggests things haven't changed much.
A huge portion of all Mail users use it exclusively via the web. That an archaic non-web protocol might bounce those messages from site to site is besides the point.
I don't want to get axod started on IRC.
Groupware is exclusively the province of the net now. Even in big companies, which have coalesced around Sharepoint.
Usenet was supplanted by blogs, blog comments, blog-search, and news aggregation sites.
Wave robots can do anything, including publishing from a wave to somewhere else, filtering and parsing, importing content, linking, whatever. They're bidirectional pipelines! And that means they're a fantastic tool for automating things, and what's more, they're easy to explain to people less technical than us mob.
Imagine this: "here, i'll copy in the room booking robot", which goes away and reads the wave to book you a room, just as you might copy a secretary into an email conversation if you were lucky enough to have administrative support...
Two of the web services I've got most from recently have been Highrise and Tripit, in both cases because I can just forward them stuff and what I wanted to happen happens. Google Wave makes building that kind of app much, much easier.
That gets my attention, anyway.
The headline is a claim about what Wave is and not about how it came to be.
I'm not an insider and I probably haven't studied Wave as closely as Ozzie['s staff], but it appears to be consistent with web architecture: the interactions are basically stateless client-server, there is a uniform interface for operational transformations, it accommodates caching, and it imposes enough structure to support layering.
Four principles for being pro-web:
1. Use URIs as names for things
2. Use HTTP URIs so that people can look up those names.
3. When someone looks up a URI, provide useful information.
4. Include links to other URIs. so that they can discover more things.
(From Time Berners-Lee's essay on linked data: http://www.w3.org/DesignIssues/LinkedData.html )
I'm not saying email is bad, it's just not part of the web.
Sure it is, like any other text-based document.
and not linkable
Well, it does have a reply-to header that's used to construct the tree of the conversation. Other than that public mailing-lists are exposed on the web.
one cannot usefully add to the amount or quality of information on the web by email
Email is good for private conversations. And for public conversations, whenever I search something on Google I often find answers from mailing-lists, exposed through a web interface.
That's pretty much as part of the web as it can be.
You'll have a much tougher time integrating Skype's audio conversations with the web for example ... it's not an open protocol, and it is not text-based. Flash was also a problem for a long time, even though Flash interfaces are served from HTTP servers. Adobe may have released tools to extract metadata from Flash movies, but it remains to be seen if those tools can be used effectively.
These are better examples of what it means to be truly web-incompatible. Email is not because it can be served through the web, and it's also a painless process.
I like mailing lists more than I like forums. With the tools available I can easily filter messages ... block people I don't like and tag messages related to a certain subject of interest. An online forum can support these features, but it usually does not.
That's the problem with online interfaces ... if the web interface doesn't provide an API to plug-in external tools then you cannot adapt it to your needs. And that's also why (IMHO) older protocols, like Email and IRC are still around and popular.
Google's demo was the possibility, and, yes, it was a shiny system, but I don't get the impression that Google is trying to sell that system. They are pushing the underlying architecture and protocols. Their demo was made up of several "independent and interoperable implementations of services from toolkits of foundational technologies." And the "foundational technologies" is the Wave protocol.
However, that's exactly what I don't like about a lot of Microsoft's software. Outlook for instance, tries to include every feature you need in your office, and it crashes on me all the time because it has too many pieces.
Please note that in saying this, I do recognize that the man they are talking about doesn't seem like the kind to always tow the party line at Microsoft. After all, he said their mindset was "scary" when he got there.
seems like its a big idea, sure, turning conversations into objects, but its not something that precludes writing smaller programs to do specific jobs with respect to the objects. google is working on the outlook-in-scale type application in order to try and fully display the possibilities of the wave concept, but the open system will (seemingly, to me, at least) allow for apps with specific purposes. sleeker apps to do smaller jobs and use the objects to interact.
That said, I think Wave is VERY WEB. Which is exactly why it stands a chance of succeeding where Ozzy's attempts have failed. I looked at the protocol and it doesn't seem all that crazy or complex. Robots can be written in any language as long as they can read and write JSON over HTTP. Gadgets are written in HTML and Javascript and are deployed over the web. It appears that near 100% of the gadgets and robots they demoed are UNIX-style "small, well-written programs that do one job well" and they plugin to a more complex UI.
Distributed, micro-kernel applications -- like the web -- do not preclude big ideas and large host apps. Browsers themselves are incredibly complex. If Wave proves to have utility and people use it, I don't see how it could fail.
I tried Groove back in the day, and it was actually one of the first "prior art" things I thought of when watching the Wave demo video. And, IIRC, Groove's backend was some sort of XML database....
It was exceedingly simple to build simple network-based applications that would pretty much instantly replicate to wherever you wanted it. The applications were not very pretty, and all had a similar look and feel. It was extremely imaginative. I remember Bill Gates even back then, while taking a jibe at Ozzie for putting an OS in the product, said that he was one of the smartest programmers out there.
The web kind of changed everyone's way of thinking about that sort of stuff, and Notes kind of faded.
I am not quite sure what being anti-web means. If web means nice GUI brower stuff, then maybe, but if you think of web as being protocols with clients and servers, then I wouldn't agree.
And now, here comes Google and boom, everyone wants one.
If you're trying to say that the browser sucks, I don't entirely disagree. I'd love to see web-aware apps with better development frameworks take over, in place of trying to shoehorn applications into the browser.
The browser is not a very good application platform, but that has nothing to do with Google Wave.
Next they will be complaining that Wave doesn't use open data formats.
Wave is defining a new set of interoperability standards for everything like a conversation.
And of course this is coming from a top executive at one of Google's main competitors. They don't have a history of saying nice things about Google, Apple, etc.
This may be kneejerk, and I don't know anything about Mr. Ozzie, but try reading it this way: "Google's new web thing denounced by maker of competing desktop things."
Even if he's right, it just doesn't sound objective.
Ozzie's arguments as presented in this condensed article seem vague to me. I'm not sure if he's trying to argue that Google Wave represents the AOL "walled garden" approach. If so, I don't think Wave is comparable.