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.
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.
UPDATE: Here’s the thread so far. Looks like assets and migrations will be in! Very exciting news indeed.
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.
