I was sitting at my desk going thru a mental checklist of things that need doing in the final couple of days before I travel to the 2010 Mozilla Summit (wow it’s like 4 days away!) and I read on one of the Moz Forums about someone asking for an .ics file of the schedule…

Hmm, I know VCALENDAR and can hack-parse html …

So 3 hours later and I have a very basic program that reads the Schedule wiki page, sucks out all of the tables that represent the daily schedules and generates a .ics ready for importing into your favourite calendar program.

Requires Python 2.6 or 2.5 with ElementTree installed: generate_summit_calendar.py

enjoy!

Just wanted to jot down some notes on what I had to do to get the XMPP console client MCabber to build from source on my MacBook Pro:

Note: If you run into any configure or make issues you may need to install some of the from-source tools I had already in place from my work to get Mozilla Firefox to build from source. I’ve covered that in detail on my Mozilla wiki page.

I used the current source tarball from the MCabber site – make sure you get the MCabber source tarball and also the Loudmouth library tarball.

Extract both into your favourite working/source tree setup

tar xf loudmouth-1.4.3+gitb5a9de5b.20100413.tar.bz2

tar xf mcabber-0.10.0.tar.bz2

Build the Loudmouth library. Note: I put all of my source installed libs into /opt that way I can set LDFLAGS and CPPFLAGS to point to anything non-OSX that i’ve installed.

cd loudmouth-1.4.3+gitb5a9de5b

./configure –prefix=/opt LDFLAGS=”-L/opt/lib” CPPFLAGS=”-I/opt/include” –with-ssl=openssl

make

sudo make install

Switch over to the MCabber directory and build it

cd mcabber-0.10.0

./configure –prefix=/Users/bear

make

make install

and that’s it – you now have a console XMPP Client!

First, it’s not the “Twitter API” if it’s found on WordPress or Tumblr (not to mention that this API compatibility has been in Identi.ca (aka Laconi.ca) for almost a year now) – it’s just an API that is Twitter-compatible.

Second, the endpoints used to access an API are, at most, 1/3 of what makes up an API – the most important part of an API is the data passed to and also from those endpoints to do the tasks that the endpoints enable.

So sure WordPress and Tumblr have a Twitter-compatible API but what happens when Twitter changes how one of the endpoints work, like they did when they recently changed how since_id works or even how re-tweets work. At best the other sites will be able to make similar changes but the worse case scenario is that they won’t or cannot make the changes and then things start to get ugly. Anyone remember RSS 0.93? or even the blog related API’s to make posts from clients – all suffered from fragmentation.

That is not to say I am not excited to see the API pattern used by Twitter is being more widely adopted, it’s a well thought out and functional API – I just think that crowning it the King of micro-blogging APIs is a bit premature until the *whole* API, data formats and all, is documented.

Wanting to be ready for the day when Google Wave opens the federation spigot, I decided to revisit the FedOne component reference code and get it setup with my test XMPP Server.

After following the normal Prosody install methods and this time making sure my SSL environment is clean, I then switched over to the wiki pages to get the component configured and installed. Except for the small bit about Java SSL code (FedOne is written in Java) not liking good old normal PEM formats, everything went according to the documentation – go figure! ;)

Anthony Baxter clearly documented installing the component into the Prosody environment on the FedOne wiki so I don’t need to go into messy details here – thanks Anthony!

After restarting Prosody, running the FedOne component, it’s time for a test and thankfully the Google gang included with FedOne a basic command line client to test with:

./run-client-console.sh username

Following this wiki guide on how to use the test client, I was able to test my local server and now I’m set for testing later – I think. :)

Total time to do the install with the following, about an hour:

• Ubuntu Jaunty
• Google Wave FedOne (w/SSL)
• Prosody XMPP server (w/SSL)

Like every other early adopter it seems, i’ve been noodling with Google Wave once my invite appeared in my developer sandbox account and I’ve been thinking/brainstorming ideas with Chris and Ken. It seems that like everything that is Web 2.0 a wave document can be both an data source and sink – processes need to be aware of this point lest a wave document just become another blog/log/journal endpoint.

What I mean is that since a wave document is an ever changing entity, any bot attached to a wave has the amazing chance to both deliver updates to the wave and also to receive updates (commands?) from the wave and I think most early bots are just doing the former.