Google Wave “is anti-Web”(blogs.ft.com)
blogs.ft.com
Google Wave “is anti-Web”
http://blogs.ft.com/techblog/2009/06/google-wave-is-anti-web/
62 comments
>> "simple to implement"
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.
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.
>> There were several people saying Jabber would kill IRC years ago
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.
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.
I wrote a Jabber client for OS X public beta back in 2000. It was a horrendous pain in the ass. I was also on the IMPP working group list for a few years.
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.
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.
From a previous thread on XMPP:
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.
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.
Yes, it's difficult to establish a secure connection. This is due to the nature of security in general, and is not inherent to XMPP. If you want to just write plain-text messages without authentication, you could do so with netcat. If you want to use digest-auth and SSL, obviously the client and server will be more complicated. Many servers will outright refuse to authenticate a connection unless it's using TLS and digest auth, which is an excellent idea.
I don't think expecting any modern protocol to support typing commands in by hand over netcat/telnet is reasonable.
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.
You've yet to state how using XML as a serialization layer introduces any additional complexity into XMPP.
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".
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".
It's about 3 times the bandwidth for a start.
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.
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.
3 times epsilon is still epsilon. The bandwidth taken by plain text, even assuming worst case overhead of many small one-character messages, is inconsequential compared to images or videos.
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.
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.
>> "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 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.
>> "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.
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.
"You've yet to state how using XML as a serialization layer introduces any additional complexity into XMPP."
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.
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.
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.
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.
Instant messengers are not yet "part of the web", but are trending that way (my family uses Google Talk via the GMail page, for instance).
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.
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.
This isn't my idea, it's my colleague's, but he managed to get it through my thick skull this morning: it's all about the robots.
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.
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.
It seems the age of intelligent agents may have finally arrived. (http://en.wikipedia.org/wiki/Intelligent_agent)
According to the article, Ozzie objects to the way that Wave has sprung almost-fully-formed from Google rather than evolving slowly by the codification of observations about successful implementations.
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.
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.
IM is "anti-web" too, and its doing fine. While the Google Wave client may be too much, the open wave protocol represents an improvement over http and im protocols in use today. I'm sure that it will find its niche(s), and perhaps become mainstream when it finds its killer app (which may or may not be from the big G).
I'm not arguing - I'm just curious, but what makes you say that IM is "anti-web"? Because it's private? Or because the current maintstream protocols have adopted too many features?
The web != the internet. IM uses the internet, but is not part of the web because you can't link to an IM.
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 )
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 )
So email is anti-web? Skype is anti-web? I don't quite see why anti-web is a bad thing anyway. Why does it really matter?
Exactly. You have just stated the main reason why this article is wrong.
Email is not indexable (I mean by search engines) and not linkable, and therefore one cannot usefully add to the amount or quality of information on the web by email. It doesn't matter how relevant your email would be to someone else; if they're not on the TO: list, they're not going to get the data. Even if you put a URL in an email, there's no way for the web to represent the relevance of the email to the linked page. Also, you can't link from one email to another.
I'm not saying email is bad, it's just not part of the web.
I'm not saying email is bad, it's just not part of the web.
Email is not indexable
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.
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.
The very fact that email needs to be pumped through a web server before it enters that workflow somewhat proves the point. Email is not linkable or indexable before you turn it into a web page. Therefore, it is not a web technology.
Email may not be a "web technology", but integrating it with the web is easy, because it is still just text based with an open and simple protocol.
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.
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.
[deleted]
Things that are part of the web work in browsers and are linkable. The rest of it is just opinions.
[deleted]
I think his point is it's "anti-web" but who cares? The internet is not just about the web. Saying something is "anti-web" is not necessarily an argument against it by itself.
IMs communicate over their own protocols, such as XMPP or OSCAR, not the Web.
Ozzie may be right, but only if one tries to implement Wave on top of the web. Sure the interface may be on the web (for some Wave clients), but the underlying protocol, from my understanding, works along side http. Similar to how smtp works along side http even if the user interface is on the web.
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.
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.
He makes a good point. After all, that's what the UNIX philosophy is all about - small, well-written programs that do one job well, and can work together easily. I like having a lightweight IM client, and regular email. From what I've seen of wave, I wouldn't like it. I think this articulates very well what I didn't like about it.
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.
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.
Has anyone ever actually used Groove? Or Mesh? They are both awful. I've heard Lotus Notes was even worse. I don't really put much weight on Ozzy's opinion.
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.
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.
Lotus Notes was a very imaginative product. I used it for a while at a couple of clients while I was consulting. One application was to build a moderately sophisticated document tracking workflow process. The other was to build various small databases for status reports and project status applications.
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.
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.
I get the feel that Ozzie feels upstaged by Google. He's been trying really hard to do "collaboration tools" since Lotus Notes with not much mainstream success.
And now, here comes Google and boom, everyone wants one.
And now, here comes Google and boom, everyone wants one.
Yes, I see the underlying platform of Wave as basically distributed version/concurrency control. I don't believe that one must use any of the Wave client stuff to interoperate. Furthermore, isn't this just a matter of degree vs. kind? One could make the argument that the standard for an email message is overly restrictive or that IM protocols limit innovation.
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....
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....
i dunno. maybe its just me, and maybe i haven't read up enough on the plans, but it seems that the concept behind wave isn't as monolithic as its being made out to be here.
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.
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.
Well I certainly need to learn more about the protocol itself before I can say anything more intelligent on the topic. If anyone wants to join me, I just found this site, which I wasn't aware of, before:
http://www.waveprotocol.org/
http://www.waveprotocol.org/
[deleted]
Wave fits the Unix philosophy more than those small, well-written programs that do one job do. The unix philosophy isn't about single purpose programs vs. all-encompassing beasts, it's about interoperability. In unix, this meant line oriented text files, and lots of programs that can deal with that. Consider 'ls': it prints in single column format when the output is not a tty, so that you can easily consume the output elsewhere.
Wave is defining a new set of interoperability standards for everything like a conversation.
Wave is defining a new set of interoperability standards for everything like a conversation.
>"small, well-written programs that do one job well"
Like a browser thats an integral part of the OS and can't be removed.
I don't see what this has to do with the topic.
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.
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.
A company whose browser requires an entire operating system, whose mail reader needs MS-Office to view documents is complaining that Google doesn't follow the - "small programs doing one thing well philosophy"!
Next they will be complaining that Wave doesn't use open data formats.
Next they will be complaining that Wave doesn't use open data formats.
People seem to forget that the internet isn't just "the web". It's simply not realistic for certain applications to be built on the web (I mean the Wave protocol, not Google's Wave client)
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.
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.
"That was the verdict of... Microsoft’s top software guru"
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.
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.
Why do we care what the creator of Lotus Notes has to say regarding the web?
[deleted]
I was mentally replacing "Wave" with "Azure" and it made the article much more accurate. Just sayin...
To summarize, Wave does not kiss.
My foot.
->"Rather, it is an attempt to foist a fully-formed, complex system onto the online ecosystem, and the Web rejects such approaches."
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.
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.
I disagree with that quote by Ozzie. The wave protocol is an extension of an existing IM protocol. The app is a combination and rethinking of existing web concepts (IM, email, and others). This isn't something entirely new. Also, other providers, along with robots and gadgets, do not need to be nearly as complex as the Wave app to participate, allowing more interop than is possible now with the old protocols.
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.