Martin Bishop recently asked me why he couldn't see my User Tune from the tooltip of my entry in the MUC room occupant list. Naturally, we were both using Psi where PEP info is often displayed in the tooltips of the Contact List entries. I explained to him that some MUC rooms can be configured as anonymous where the JID of the occupants are not exposed. Without the JID of course, you would be hard pressed to figure out a way to determine whose PEP nodes to retrieve, not to mention determine subscriptions and node access models. However, after answering his question I had an interesting idea for an Openfire plugin...

Remember during the stone age when people used IRC? Neither do I, but stay with me. There were many client side scripts that let you type a command and have your currently playing song sent to the channel. In fact, when I used Kopete there was a plugin that did the very same thing, even over Jabber. So, the idea was to provide that same functionality, except server-side instead of client-side and utilizing PEP.

Thus, last night my friends and I came up with an Openfire plugin called PEP in MUC.

Sending one's tune to the room:

Currently you can also send your mood to the room in the same manner. There are some caveats of course. This only works for local users to the server, and by its nature the node access models are not being respected. But since the user themselves are initiating the 'explicit pubsub notification' this latter caveat does not seem like an issue to me.

Grab the plugin for your Openfire server and ... revert back to the stone age?

Openfire now has a complete implementation of Personal Eventing via Pubsub (XEP-0163). According to Gaston, my work on PEP will be included in the next Openfire release (3.4.0 I believe). For more information on the implementation and pointers to its source code, visit the project's section on my main site.

Below you will find the deliverables that I indicated I would provide in the Google Summer of Code proposal at the beginning of the summer:

• System test plan document
• Architectural and detailed design document
• Implementation disseminated through a SCMS
• Documentation
• Report on final testing and evaluation will be available on code.google.com in the GSoC dashboard.

With the meat of this post out of the way, I want to let it be known that I had an absolute blast coding this summer. Meeting Gaston and being able to collaborate with him in person at the Jive offices was a real highlight of it all. I am looking forward to further collaboration with Gaston as I maintain the PEP implementation in the future. I am also happy to have met everyone in XSF, including Peter Saint-Andre and Kevin Smith. You guys are awesome.

My efforts will not stop here. With new versions of XEP-0163 and XEP-0060 on the way, I have already talked to Gaston about helping to implement these new versions in the future.

Until then, cheers!

I am pleased to announce that the Google Summer of Code project to implement PEP in Openfire is very nearly complete. It is indeed usable at the moment and further below in this post you will find a public test server running the latest revision available for you to play with.

A whole lot of progress was made in the last two weeks, including implementations (along with c2s and s2s verifications) for the following sections:

• Account Owner Publishing
• Contact Notification Filtering
• Generating Notifications
• Sending the Last Published Item
• Recommended Defaults

The only section left to implement and verify is 14.1: 'Cancelling Subscriptions.' The PEP project page on my main site has a table with the current status of the project. That page might also contain links to a beta release with pre-compiled JAR packages available to download in the near future.

Until that time comes, you are welcome to join my friends and I on the public test server by connecting to jabber.esoteriq.net. If you are looking for a Jabber client to test PEP with, I recommend using either the latest version of Psi or Coccinella from their respective versioning repositories. Keep in mind that this is a development test server. Expect restarts, database resets, and even temporary downtime when the server gets updated to the latest revision. Join us in the group chat at pepdev@conference.jabber.esoteriq.net and say hello . Direct bug reports (and/or praises ) to one of the addresses listed in the contact section of my weblog.

Also, thanks to Ben Slote for generously hosting the public test server.

Last Wednesday I was informed that I have been accepted into this year's instance of the Google Summer of Code program! I was extremely excited when I received confirmation as I am going to have an absolute blast coding all summer. Approximately 6,200 university and college students applied, and this year over 900 were accepted (up from about 600 chosen for GSoC 2006).

The organization that I aimed my winning proposal at was the XMPP Standards Foundation (XSF). The abstract of the proposal is available here. Many of you who know me also know how great of an instant messaging network I think Jabber is--so it goes without saying that I am more than pleased to be implementing a new portion of an awesome protocol like XMPP (in an equally awesome cross-platform Jabber server, Openfire).

As if this news was not amazing enough, my good friend Jared Hendry (buchan) had his proposal to the Mono Project accepted as well!

WIN.

This is a generalized wrapper script around rsync that I use to keep my website synchronized to a local directory on my workstation. rsync is a powerful tool. Instead of using an ftp script that just blindly overwrites any files you tell it to, rsync actually uses a differential algorithm to only transfer the bytes that have changed. On top of that, you can compress those bytes before the sync, resulting in an even quicker transfer.

I have instructed esosync to call rsync with a number of useful options. Here's a snippet from the script:

'--verbose',            # increase verbosity
'--progress',           # show progress during transfer
'--stats',              # prints extra statistics
'--compress',           # compress file data during the transfer
'--rsh=/usr/bin/ssh',   # use ssh as an alternative remote shell (secure)
'--recursive',          # copy directories recursively
'--times',              # transfer modification times
'--perms',              # keep file permissions synchronized
'--links',              # if symlinks are encountered, recreate on web host
'--delete',             # delete extraneous files from the receiving side

It is a lot more useful if you have set ssh up to use a public key for login authorization to dreamhost. Then you can use this script within other scripts or a cron job. I happen to use it as nanoblogger's publish command:

BLOG_PUBLISH_CMD="esosync"

Download the script: esosync.perl

You will just have to edit a few variables near the header.

Last term one of my courses at the local university was about database management systems. From UML diagrams to foreign key constraints to Boyce-Codd normal form, it covered all of the more important topics. Towards the end of the term we were asked to design our own database and implement a client to it in a language of our choice. Ahh, a chance to code. The course became interesting all of a sudden.

I designed a database for a sort of gamerankings-esque style of handling video game reviews. With it, you can add reviews from a number of different publications and find the average (meta) score for the game. There's a few other twists involved too. You can add publishing companies along with development houses for the games and tons of other data. Then you can filter through the database on pretty much any key. If you want a list of the Mature rated games for the Super Dreamcast 360 console developed by Luser Studios, you can get one quickly.

Try out the video game database demo.

I decided to use PHP for the client since I haven't really used the language all that much. It also plays nice with MySQL, the DBMS I chose, so that was a factor in the decision as well. You might recognize the style sheet used.

I became interested in nanoblogger's support for Markdown, "a text-to-HTML conversion tool for web writers." Now I don't have a problem writing raw HTML, as I have done so naturally for all my previous entries. However, I cannot write W3C valid XHTML easily. Markdown is a plain text formatting syntax, and also a Perl program that converts the formatting to HTML.

Now, in the spirit of consistency, I have written a Perl program that converts nanoblogger's metafiles from HTML to Markdown. This may seem redundant to those who don't know how nanoblogger works.

Nanoblogger uses its metafiles to generate HTML that can then be modified and/or validated with plugins. I prefer to use a program's accuracy to ensure the HTML generated by the Markdown formatting is W3C valid. Plus, reading and writing Markdown syntax is a breeze.

If you have been using raw HTML to create your nanoblogger entries, and you wish to switch to Markdown formatting, this tool will help you cope with the thought of having inconsistent metafiles. It uses html2text.py so you will of course need that as well. Be sure to backup your metafiles before using this tool, as it will modify your files without intervention.

Download: nb-html2md.perl

After the conversion, I was pleased to see this site is now W3C XHTML and CSS valid.