Along with the launch of Presently.com, we quietly revamped the backend architecture of Present.ly to better use the eXtensible Messaging and Presence Protocol (XMPP) as the standard message delivery system. You may have noticed near-instant updates on the new web interface — this is primarily due to the super-fast messaging features of eJabberd, the XMPP server that Present.ly runs on.
We believe that XMPP will play a bigger role powering dynamic, real-time web applications in the coming years and have previously blogged as such. While most people in the industry know of XMPP only in its instant messaging role, the fact that there are fully fleshed out specifications for most common enterprise messaging problems as subsets of the XMPP specification is often sadly overlooked.
So what does this mean for Present.ly? In the short term, as you may have already noticed, you will see a major speed improvement posting and receiving updates. In the long term, we are planning on making our user interface a lot more dynamic — details are top-secret at the moment. We are also working on moving over our notification systems completely to XMPP, which will result in you receiving update notifications more rapidly over all your devices. As we grow, we’ll be leveraging eJabberd’s high scalability (due to it being written in Erlang) to provide a seamless, quick user experience.
We are also actively contributing back to the open-source XMPP community. Read about ruby_bosh, the first Ruby library to handle BOSH sessioning in your Ruby applications. We have also made various stability and speed fixes to the stropheruby library, which is based on the libstrophe C library (announcement soon). Both are available on Github for general use. Intridea’s proud to be a part of the XMPP community, and will be heavily using and promoting the technology with both our products and services.
Hot on the heels of my post on why XMPP will be huge, here’s a ruby library to pre-initialize BOSH sessions in your Ruby web applications. This feature allows you to by-pass exposing your user’s XMPP credentials in your HTML views.
The process follows as such:
Start your XMPP server and create an account for your web application user.
In your Ruby application, use ruby_bosh to initialize a new BOSH session using the user’s xmpp username and password.
Pass the identifiers returned from ruby_bosh to your template engine as variables.
Bind the template variables to Javascript variables.
Use a Javascript-based BOSH connector (like Strophe) to attach to the pre-existing session using the identifiers.
There are many XMPP servers and BOSH connection managers out there, but as of now this library has only been tested with eJabberd 1.2+. Please feel free to fork and submit a pull request if you’d like to contribute.
The maturing of the BOSH protocol, coupled with the resurgence of excellent Javascript libraries have, IMHO, opened up extremely cool new worlds via the browser. Strophe, in itself, is a treasure.
XMPP servers, which are essentially make or break an XMPP application, are rapidly maturing beyond instant messaging. Especially eJabberd.
It’s possible to deploy a custom eJabberd module based on the XMPP protocol but tailored specifically for your application in a matter of hours. The initial learning curve is offset by the rapid development speed of the Erlang language (thanks to its immutability) afterwards.
While there’s a lot of focus on developing pure web applications, as of now nobody has figured out a great way to make money off the Instant Messaging protocol. This will be a boon for XMPP development very soon as new startups try to tap into that market.
The web framework wars are slowly winding down, and in the end developers are left with the classic problems — many will now be turning to alternative tech for the problems that most web frameworks don’t even attempt to solve; XMPP is the solution for most of these problems.
Apart from all of these, as a developer I find writing XMPP applications to be a very engaging and enjoyable activity. Word will spread, and there will be new converts. At Intridea, we’ve been actively developing and integrating XMPP into our products, and we will be leveraging it on a case-by-case basis for our client work. You’ll be hearing more about that soon.
As of commit 5fa0457 (on Thanksgiving Day 2008, nonetheless), Edge Rails is getting work done on having plugins as engines. An engine (as of now) is defined as a plugin that has an app/ folder, which includes controllers, helpers, models and views. There’s also support for plugin routes at this moment.
As of the commit mentioned above, Rails engines are not yet app slices. A slice, at least in my opinion, contains its own assets (public/) and its own migrations. In essence, a slice would have the same structure as a regular Rails app. Not sure what the core guys have planned, but also having support for these two would greatly improve on the value of writing engines.
This replaces the old components framework, and paves the way for a new way of writing re-usable Rails plugins. For example, the 15-minute blog screencast can easily be reworked to be an engine and re-used within multiple apps. You can also write engines for audio, video, maybe a wiki engine and so on.
We’ve been working on the problem of sharing code between multiple apps for quite some time now at Intridea, and I’ve also been talking about it a lot at RailsConf Europe with Michael Bleigh and at Bay Area Ruby meetups. The commits I’m noticing in core are great, hopefully soon there will be some more relevant work into officially namespacing the new code so that engines are distinct from plugins externally; storing them in vendor/engines or app/engines would also be good — a clean codebase is always something to look forward to.
I went to see Dave Chappelle’s stand-up show twice recently at the Punchline Comedy Club (in the span of one week). The man’s a genius, to say the least — the past two years since his show went off the air has definitely helped him perfect his timing and delivery. His on-stage presence and stamina is also extremely admirable — the second show lasted five hours, and he was on top form over eighty percent of the time (”You know what a 7 hour Dane Cook set’s called? Unfunny“)
Chappelle’s Show, besides being ground-breaking and overall excellent, wasn’t really intellectual entertainment of the highest order (though it was quite smart most of the time). So it was quite surprising to me when Dave Chappelle talked a bit about Ayn Rand’s Fountainhead (”I hate Ayn Rand. You’re never gonna hear s— like this at a Carlos Mencia show“). I never made the connection, but once Chappelle started comparing himself to Howard Roark (the protagonist) on-stage, the similarities were quite striking. Both were men of a singular vision, who destroyed their very creations instead of compromising their art.
I have never seen Chappelle’s standup show before, but I have to admit that I found his calmness and style quite disarming and comforting. He genuinely enjoys doing what he does, and the level of clarity and cleverness he employs during his shows definitely made an impact on me. There were many, many memorable moments, one I remember vividly was him saying “..what I try to do at every show is to strip away that veneer of celebrity, so that you people start seeing me for what I am“. One of the other illuminating moments came when he mentioned, cigarette in hand, that all he did nowadays “was read one good book after another“.
I track ‘dave chappelle’ on Twitter, and I’m convinced that Chappelle’s popularity’s growing exponentially the longer he stays off the air. The outcome of the elections have people clamoring for his return, hopefully we’ll see more of him on the air.
Oh, apparently he’s “David Chappelle” on Facebook. I’ll let you find that one out for yourselves
I’m quite bad at blogging, I’ve noticed. Hopefully this one will go better.
Who is this?
This is Pradeep Elankumaran's online presence. I'm a Ruby/Rails/Erlang hacker, and Intridea's Director of R&D. I live/work in the Bay Area and Washington DC.
