Buddycloud Media Server Architecture

After some conversations with my mentor (dodo), we finally have a bigger picture of how should work the media server communication flow, here is a short description of the "posting" media functionality:

1. Client discovers the channels media server;
• Since it is a XMPP Component, it should be "discoverable";
2. Negotiate media url; 
3. Client receives a link for public channels and a cookie for private ones;
4. Upload data, PUT or POST request to the media server http static file server.

Here is an architecture overview diagram:

Where:

• Media Server:
• HTTP FIle Server: static file server, where clients will be able to GET and PUT (or POST) files;
• XMPP Component: component that will evaluate user's permissions and also generate valid URLs for the client download or upload files through the HTTP File Server.
• Storage:
• Medatada: stores files metadata, like checksum, upload date, etc;
• Binary Files: stores the files themselves (and also their previews).

That means, that both Media Server and Client should talk two "languages", HTTP and XMPP.  But this would change (or not) after Denis, the other buddycloud's GSoC student, finishes his project.

Google Summer of Code 2012

This year I'm participating of the Google Summer of Code for the first time, I'll be working with an exciting XMPP project called buddycloud.

The project title is An XMPP Media Server, it basically consists of the development of an XMPP based media server that will have a HTTP face to facilitate the use by different types of clients.

The media server should be responsible for getting, adding and deleting of files (images, videos and documents), treating properly of the authentication process and also providing previews if the client doesn't want to download the whole stored file. That's why this project should bring even more developers for the XMPP world.

I will be reporting all the process evolution, problems, challenges and ideas at this blog =)

Hadoop + Amazon EC2 - Using Apache Whirr

Apache Whirr is a set of libraries for running cloud services. You can use it to create EC2 instances running Hadoop, just like the previous tutorial. But, Whirr also provides a lot of other interesting functionality that worth to give a try.

Other advantage is the possibility to run into different cloud providers without worrying about each one configuration details. Of course that you need an active account.

You can find a simple tutorial at Whirr's homepage: Getting Started with Whirr.