Google Wave is not the answer, XMPP is!

Written on 1:00:00 PM by S. Potter

Since yesterday afternoon (my time) all over the Twittersphere (and blogosphere) I kept hearing a ton of great reviews of the Google Wave API/protocol and how it will revolutionize communication and collaboration on the web. This morning I watched the Google Wave demonstration from yesterday and I have to say I am completely underwhelmed considering everyone else's reactions were ridiculously positive and had nothing measured or thoughtful to say about it. You can find my initial reaction of it, "Google Wave is just a simple XMPP extnesion", on my tumblelog. As someone that has had to write XMPP extensions for clients and my own internal apps, servers, API interfaces (mostly distributed monitoring of services, but a few more for media processing) I am saddened that anyone would think the current Google Wave protocol (which is just an XMPP extension) is extraordinarily ground breaking. There have been a number of existing extensions that tried to do VERY VERY similar things already and specific features of Google Wave were already exactly defined. What made the demonstration of Google Wave yesterday appear so impressive were the applications: the wave client and the web embedding. The responsiveness of the web application really made it stand out, NOT the underlying Google Wave protocol/API. For those who have never really gotten their hands dirty with XMPP in any real technical way, I expected they would not really know what it already provided in XMPP. Many "geeks" hyping up Google Wave seemed to think XMPP only supported instant messaging. That just happened to be the most popular and apparent XMPP extension, which many people call Jabber. XMPP itself is a lot more far reaching than just an instant messaging protocol and the fact that Google Wave was based on top of XMPP should tell you how flexible it is. Yes that is right, Google may not have really made a big deal about it (why would they if they can get extra credit when it isn't due), but Google Wave is just an XMPP extension and compared to other extensions I have had to interface with, not a particularly complicated one. Sure the applications that Google demonstrated as part of the Google Wave presentation were nifty for personal communication, but are they really ground breaking, multipurpose, or ubiquitous? No, it is only as ground breaking, multipurpose and ubiquitous as it's applications make it. Let us all now return to earth for a moment and praise Google for the things they do really well like web applications, but let us not pretend that Google is the mover and shaker in terms of the visionary of future underlying protocols. They still advocate developing HTTP applications for the future. HyperText Transfer Protocol (HTTP) is virtually on every digital device made by man today, but does it really lend itself to providing the distributed service oriented architecture we should be striving for and the protocol of the future? REST is not about the HTTP protocol. RESTful APIs can be creating in a number of ways and through a lot of different protocols. My take is (from a technical level) XMPP ought to be the protocol of the future, NOT XMPP on just the back-end and then adding tons of bloatware in between the client and the service just so that we can create an API or UI on top of an antiquated protocol (HTTP) that has seen better days. Anyone want to create a truly modular XMPP "browser" for the new "web" with me? Email me at susanpotter dot net if you want to join the future. UPDATE: Please subscribe to the "Join the Future" Google Group if you want to get involved in the XMPP browser project.

Related Links

Erlang doesn't support currying? News to me!

Written on 4:13:00 PM by S. Potter

I keep seeing developers who only glance at Erlang and think that currying isn't supported. Nothing could be further from the truth...unless you are defining currying support only in terms of specific syntactic sugar in a language for currying. So let us step back and define what currying support really means:

Currying is the process of transforming a function that takes multiple arguments into a function that takes just a single argument and returns another function if any arguments are still needed. http://www.haskell.org/haskellwiki/Currying
Let us look at a simple (but hopefully not too contrived, albeit it _slightly_ contrived) example:

%% currying_example.erl
-module(currying_example).

-compile([export_all]).

multiply(X, Y) -> X*Y.
doubler() -> fun(X) -> multiply(2, X) end.
In your erl shell try the following:

1> c(currying_example).
{ok,currying_example}
2> D = currying_example:doubler().
#Fun
3> D(6).
12
4> q().
ok
As you can see in the module code above, Erlang supports what is called anonymous functions (e.g. fun (X) -> somePredefineFunction(OtherVarOrConst, X) end), which then allows us to manufacture single argument functions in a way that is clear and expressive in the code IMO. For those that haven't been following the functional programming debates over the last week or two around the blogosphere, please see the following blog posts (some are pretty funny and will make you smile at least twice with their intended absurdity): Previous posts on this blog that are related are: I will try to put together a few snippets on currying support in Python, Javascript and Ruby tonight after my Greek class (which I am late for now) if I have time as a quick exercise:)

Twitter4R 0.3.1 and the future

Written on 12:16:00 PM by S. Potter

Hi Twitter4R users, I know I have been rather absent in terms of my Twitter4R contributions and ongoing development, but despite my absence I have _finally_ officially released 0.3.1 with a lot more new features and a few bug fixes more than I initially expected to release 0.3.1 with. Some of the goodies included in the official 0.3.1 release are:

  • Added raw Twitter Search API support. Meaning you can use any of the HTTP parameters the Twitter HTTP-based Search API will expect. E.g. twitter.search(:to => "twitter4r", :rpp => 10) or twitter.search(:q => "twitter4r", :rpp => 15, :geocode => "40.112186,-88.207592,250km")
  • Profile, theme API coverage on Twitter REST API.
  • Social Graphing API. E.g. twitter.graph(:friends, user)
  • Added "reply" support at all levels (low-level to model-level)
  • Bugfix: the infamous URI.encode to CGI.escape change.
  • Rate limit information (still needs to be able to support the HTTP header method, which I actually suggested to Twitter developers some time back, but they only recently added it when my bandwidth for OSS contribution was minimal) :(
  • much more
Now the future of the Twitter4R project. I have made a LOT of mistakes with this Twitter4R OSS project venture, so I am going to try to fix a bunch of these things:
  • Create a new set of Git repos on GitHub that separates the education portions (screencast, etc.) from the core source code of the project so that people do not need to download ridiculous amounts of data to their local drive just to fork Twitter4R on GitHub as it required at present. Announcements about this will be coming soon!
  • Have a consistent issue tracking system for Twitter4R. Previously it has appeared inconsistent to users of the Twitter4R library where to submit defect reports or new feature requests to. So I have had to field these requests from the Google Groups mailing list to personal emails and also @twitter4r replies on Twitter. I plan on using GitHub's new issue tracking system for this as it seems a logical extension.
  • I plan on documenting things a little more obviously on the official website from now one. It appears many users did not want to go to the RDoc unless specifically pointed to it, even though a large majority of the library is fairly well documented in the RDocs.
Please be patient while I fix these process/marketing/workflow issues of the project and in the mean time I will also be tackling OAuth support as well. Again thanks for your patience thus far and tweet me on twitter at either @SusanPotter or @twitter4r if you have suggestions or questions about the direction. If you have specific queries on using the actual API, please join the twitter4r-users Google Groups mailing list and search the archives for a solution first and then if you can't find a solution, please post a message giving the group members your environment details and the version of Twitter4R you are using. Thanks! Susan Twitter4R Developer