Drupal Push, Or: How I Learned to Stop Worrying and Love the Rest of the Net

Overview: Adding outbound methods of communication to Drupal. The services module exists to allow other services to communicate with Drupal but there is no easy way for Drupal to tell other services information about its own content.

Description: There are a number of services which would be beneficial for Drupal to implement. I think that building them as a set of actions would probably be best, as actions already provides a simple event mechanism for when things should be pushed out.

One example would be to implement different social network apis as actions. When someone posts a node, a link is automatically posted to their Facebook profile. This is not my favorite idea but one that's easy to imagine and probably implement.

More interestingly, having Drupal make (XML | JSON)RPC calls to another server. It would allow different servers to synchronize content without one having to poll one another. Providing a ui that allows an easy mapping of values and fields to ones that another server expects, as well as making sure that only the data that's intended to be sent is actually sent would be important. No data leakage.

The gdata api would be very interesting as well. Being able to aggregate your own Youtube feeds, having certain nodes be uploaded to Google docs or base, or syncing calendars with Drupal and Google Calendar would all be very useful.

The most AWESOME idea however, would be to provide STOMP support to Drupal. This would allow communication with other servers as well as direct page updates through Comet. There is a rather good Stomp client for php, one thing to research would be whether or not it would integrate well with Drupal or if a new one would have to be written. I know for a fact that it does 'work', I just haven't tested it thoroughly. The biggest dilemma in my opinion would be attempting to support the whole protocol, as there is a subscribe mechanism as well as a sending mechanism. I have written middle wear in the past that listens for Stomp messages from a message broker and then calls Drupal through the Services module, but that was tedious and more code to maintain. Trying to make these services abstract enough so that they'd be useful for a wide number of use cases would also be difficult. The results, however would be astounding. Drupal would be the first major CMS to support automatic page updates without polling.

The current state of the technology is frustrating with many half working implementations using incompatible technology. Dojo is trying with their Cometd, but for some reason they have four or five different server implementations. The best route to go in my opinion would be Orbited. I have had success using their stack in the past on other projects and it works well. Web sockets are suppose to be coming in HTML5 anyway so getting Drupal ready ahead if time would seem like the best idea. Just imagine it though, automatically updating blocks, or views without having to poll the server. It's a thing of beauty.

I realize that there are a lot of ideas here and to implement one of them well would be more important than all of them half way. I look forward to getting feedback on which ideas would be most valued by the community. Also, there are probably modules in existence that do some of these things and integrating them would also be a major goal. The benefit of Drupal would be to gather all of these disparate services together under the same mechanism seeing as how they all provide similar data just through different protocols. The bottom line is that Drupal is such a powerful CMS, it should be easier to share all the data that Drupal sites contain with the rest of the net.

Mentors:

* None yet

Difficulty: Medium