MSRP .NET port released!

Thanks to ContactMakers effort, another port of the MSRP library sees the light of day.

The original official release info:

Greetings fellow developers,

Since the 10th of January, that the MSRP C# (.NET) version is available!

Much thanks to ContactMakers for the effort applied on the port

For more details, visit the project’s webpage here

As always: happy coding!

The MSRP team.

MSRP new version release!

So, here it is, thanks to Tom, the new final version of the MSRP Peer Java library has been released!!

This is the initial announcement:

Greetings Java developer,

After a flying start within the brilliant Google Summer of Code, having it simmer for a while and finally polishing it up with some actual use-cases, the MSRP project team is proud to announce version 1.0 of its’ magnificent library!

This is an open source library, implementing the Message Session Relay Protocol (MSRP: RFC 4975), for you to deploy in any application.

Functionalities include

- establishing MSRP sessions

- sending and receiving instant messages (chat) using MSRP

- sending and receiving files using MSRP

- message/cpim wrapping to interface with other chat systems

- nicknames (draft-ietf-simple-chat)

- message composition indication (RFC 3994)

More information can be obtained at

For a quick introduction, read the tutorial:

The entire project is hosted here:

Build versions can be found in the central Maven repository, just include the dependency in your projects’ pom.xml buildfile and you’re good to go.

So be our guest, use it, abuse it and send us your patches, comments, issues, wishlists and what have you.

Happy coding!

The MSRP team.

Special thanks go to:

- The Jitsi project for initiating this

- Google summer of code for making it possible

- Nlnet for early development sponsoring

- ContactMakers for sponsoring the polishing.

Feedback is welcomed :)

MSRP new webpage

To welcome the soon to be released new version of the MSRP library *thanks Tom*, I decided to do a complete renovation of the projects webpage. Seen that I was already familiar with the Bootstrap framework, I decided to use it. Give it a browse, and feel free to share your opinion.

Jenkins – allowing the ‘build trigger remotely’ functionality with the CAS plugin

Jenkins CI


So, right down to it, I gave the feature of allowing ‘build triggers remotely’ to the Jenkins(/Hudson) CAS plugin, thus allowing HTTP GET requests to bypass CAS authentication on ‘build triggers remotely’ links (i.e. http://JENKINS_URL/build?token=SMTHNG). It was one of my ways to give something back to this awesome tool. You can see the code here,  whose pull request has been made , alongside with its issue. Not so interesting reasons of why I did it, are detailed below, comments of code/reasons/whatever are welcome :)


At work, we are starting to use hudson/jenkins to build and deploy each module of the new Bennu structure (~61 modules, all of them a Maven project and deployable on their own, a big change from what we had).

We already used a pre-forked version of Hudson, and seen that I had to make some changes to Hudson, I decided to upgrade. So, the question was Jenkins or Hudson? I Chose Jenkins, why?! no real good reason, I wanted to upgrade, I tried to google the choice, and found something in favor of Jenkins, plus the fact that the main community moved to Jenkins and the fact that I know that corporations can be tough on O.S., and I’m all in favor of open source, I chose Jenkins :) .

Anywho, before I realized that Jenkins has SSH access (!!) I decided to tackle an old problem that I had solved before with the use of Apache, that was authentication on Jenkins through CAS. We had chosen Apache before to handle CAS authentication, instead of the Hudson CAS plugin, because it was the simplest way to allow CAS authentication while making sure that the ‘build trigger remotely’ urls (something like http://JENKINS_URL/build?token=SMTHNG) were accessible without CAS authentication for some hosts, so that my SVN hooks could have trigger the build when something had changed. We weren’t actually very happy with the Apache solution, as it sometimes the connection fails with a segfault on the Apache side (?! yeah, really!)!! not sure why, not planning on pulling out the GDB, after trying to search a bit for that bug, I just resigned to use it as it was, after all, we didn’t used the web interface all that much. Something that is bound to change with the new infrastructure used for Bennu.