Blog new address

This blog has been moved to http://rodrigods.com.

HTTP API + Media Server

It's great to see the two buddycloud's GSoC projects working together. Denis has built a toy client to demonstrate his HTTP API, and this week he adapted it to handle channels avatars provided by the Media Server. Here are some examples:

https://www.denisw.de/buddycloud-http-client/

https://www.denisw.de/buddycloud-http-client/?channel=team@topics.buddycloud.org

Also, there are some examples of already stored media:

video: https://api.buddycloud.org/media/gsoc2012@topics.buddycloud.org/Jw8Eq6kWf6m2rmAg0Nrp
video thumbnail: https://api.buddycloud.org/media/gsoc2012@topics.buddycloud.org/Jw8Eq6kWf6m2rmAg0Nrp?maxheight=150
image: https://api.buddycloud.org/media/gsoc2012@topics.buddycloud.org/avatar
image thumbnail: https://api.buddycloud.org/media/gsoc2012@topics.buddycloud.org/avatar?maxheight=200
media list from a channel: https://api.buddycloud.org/media/gsoc2012@topics.buddycloud.org

Media Server - Paging Queries

One useful type of URL query are paging queries, they limit the returned data into a specified range so, since the amount of displayed items are lower,  the interface performance is improved.

Since we are implementing a XMPP media server, would be great to have something similar to RSM (XMPP way to do pagination), at least, similar to its syntax. So, the implemented paging for the media server is like:

 GET /channel@domain.com/media?max=10 -> returns max 10 metadata media info
 GET /channel@domain.com/media?max=10&after=foo -> returns max 10 metadata media info after the media with id equals to foo

There are no new features to be implemented, so the effort in this final week is to polish the code and improve documentation.

GSoC 2012 - Last sprint

What I'm doing right now? Finishing some details, like documentation and tests improvement, also, one more feature is being planned to be added, that is a RSM like URL query, this means:

 GET /channel@domain.com/media?max=10&after=foo

Will return the first 10 metadata info (ordered by last modified date) after the media with id equals to foo.

Next monday (13th), is the suggested pencils down from GSoC 2012. It was a pleasure to work with the buddycloud team, and I've learned A LOT during this period.

Media Server is deployed!

Finished the XEP-0070 implementation, the Media Server was ready to be deployed, and yesterday the first tests with Denis' HTTP API + Media Server were excellent! Some bugs, of course, but already fixed, and we are very excited with the result of our efforts.

Although, there are some improvements needed by the Media Server for the next couple of weeks:
- Handle video media previews;
- Handle clients with bare JIDs: the XEP-0070 negotiation with those clients needs to be done via XMPP messages;
- Handle audio media: set length property;
- Documentation.

Media Server user authentication - XEP-0070

XEP-0070 is a known specification of how verify HTTP requests via XMPP. It has basically 8 steps.

In the Media Server, when a HTTP request arrives, the HTTP side forwards the request to a AuthVerifier class, this class has control over an XMPP component, to send and receive packets in a synchronous way, via a SyncReplySend util class. Once the AuthVerifier class receives the request, it "asks" if the client has sent it, if yes, the request is authorized, if not, the HTTP side returns a 403 error.

Here is the sequence diagram:

To send its credentials, the client has two options:

• Via HTTP auth: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 
• Via URL: /media/test@topics.buddycloud.org?auth=QWxhZGRpbjpvcGVuIHNlc2FtZQ==

In both ways, the client's JID and transaction id, are separated by a ; and are base 64 encoded.

This week, we hope to do the first deploy, to finally see the Media Server running in a production environment!

Media Server Pub-Sub based authentication

As already cited at the GSoC's proposal, the Media Server would use pubsub capabilities to give/deny access a channel's media.

Although the concept is quite simple, and the necessary packets to trade such information between a client and a pubsub server, the biggest challenge was adapt the Smack API to the particularities from the buddycloud's XEP. The work was a lot easier because in the last year GSoC, another buddycloud's student (Abmar Barros) had to implement similar functionality  into his project, also using Smack.

So, to verify if an user like "rodrigo@buddycloud.org" can POST a media into "private@topics.buddycloug.org" all that the Media Server does is retrieve the channel's affiliations, and check if "rodrigo@buddycloud.org" has post capabilities:

<iq from="mediaserver@buddycloud.org/Client" id="Eq5j2-2" to="channels.buddycloud.org" type="get"> 
  <pubsub xmlns="http://jabber.org/protocol/pubsub#owner"> 
    <affiliations node="/user/private@buddycloud.org/posts"> 
  </affiliations></pubsub> 
</iq>

RESPONSE:

<iq from="channels.buddycloud.org" id="Eq5j2-2" to="mediaserver@buddycloud.org/Client" type="result">
  <pubsub xmlns="http://jabber.org/protocol/pubsub#owner">
    <affiliations xmlns="http://jabber.org/protocol/pubsub#owner">
      <...>
      <affiliation jid="rodrigo@buddycloud.org" affiliation="publisher"/>
    </affiliations>
    <set xmlns="http://jabber.org/protocol/rsm">
      <first index="0">
        user1@buddycloud.org
      </first>
      <last>
        user5@buddycloud.org
      </last>
      <count>
        5
      </count>
    </set>
  </pubsub>
</iq>

What are the next steps?
- Fist I'd like to deploy a toy client to demonstrate some of the Media Server functionality;
- After that, the next step is the implementation of the XEP-0070 and documentation.