Archive for the Category code

 
 

Thoughts about all of this “Twitter API” chatter

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.

Google Wave FedOne component with Prosody XMPP server

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:

Random thoughts about including Google Wave in your data flow

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.

v0.8.7 of parsedatetime is now live

Thanks to a great bug-fix patch by Michael Lim, Issue 26 has been fixed.

This bug was preventing parsing of 25 August 2009 – which seems like a silly bug to have except when you realize that it came about from adding more robust locale support for short month/week names.

Anywho, patch applied, some other minor fixes worked in and a new release!

XMPP PubSub + XSLT

One of the niftier configuration items for a XMPP PubSub node (see Configuring a Node) is the ability to define an XSL template to allow the PubSub component to generate a message body to go along with the message payload – basically a human readable version of the payload.

This is great because it allows you to have a single node service both bots and people. Without this you would have to define proxy bots that are subscribed to nodes and then they would send out chat messages for each incoming PubSub event for people in their roster.

Not exactly a friendly model IMO.

So to prepare for this I started working on a XSLT file to transform an Atom payload to HTML – but first I needed to either learn XSLT real fast or “borrow” from someone :)…

After about an hour of googling I finally found one that a) worked and b) targeted the 1.0 version of Atom at the OpenSearch site – wow was that a gold-plated, kitchen-sink-included version! It handles Atom, RSS (all of them), RDF and some others – and after a rather great question from @metajack (aka Jack Moffitt):

Why bother with RSS at all?

I started pulling out all of the non-Atom bits. He also helped me grok a template scope problem that was leading me to curse XPath royally – thanks Jack!

So after many, many rounds of edit/test/curse I boiled it down to a basic template (tho I did keep some of their snazzy person and url templates – *very* nice!) and then proceeded to tweak the HTML it generates.

So if you pass in this Atom payload:

<entry xmlns=“http://www.w3.org/2005/Atom”>
    <title type=“html”>Test Atom</title>
    <link href=“http://seesmic.com/videos/FOO”/>
    <id>http://seesmic.com/videos/FOO</id>
    <author>
        <uri>http://seesmic.com/foobarbaz</uri>
    </author>
    <published>2009-01-03T20:46:19+00:00</published>
    <updated>2009-01-03T20:46:19+00:00</updated>
    <link href=“http://t.seesmic.com/thumbnail/FOO_th1.jpg” type=“image/jpeg” rel=“enclosure” title=“Test Atom”/>
    <link href=“http://v.seesmic.com/flv/FOO.flv” type=“video/x-flv” rel=“enclosure” title=“Test Atom”/>
    <source>
        <generator>SeesmicBot</generator>
        <id>http://feeds.seesmic.com/user.foobarbaz.atom</id>
        <updated>2009-01-03T20:46:19+00:00</updated>
        <title type=“html”>Test Atom</title>
        <rights>Creative Commons Attribution</rights>
    </source>
    <in-reply-to xmlns=“http://purl.org/syndication/thread/1.0” type=“application/xhtml+xml” href=“http://seesmic.com/video/FOO” ref=“FOO”/>
    <category term=“en”/>
    <rights>Creative Commons Attribution</rights>
    <link href=“http://creativecommons.org/licenses/by/3.0//us/rdf” type=“application/rdf+xml” rel=“license”/>
</entry>

You will get this:

<html xmlns=“http://www.w3.org/1999/xhtml” xmlns:xhtml=“http://www.w3.org/1999/xhtml”>
<body>
    <div>
        <a href=“http://seesmic.com/videos/FOO”><div class=“x-escape”>Test Atom</div></a> by
        <a href=“http://seesmic.com/foobarbaz”>http://seesmic.com/foobarbaz</a>;
        <p>categories: en; </p>
        <p><a href=“http://t.seesmic.com/thumbnail/FOO_th1.jpg”>Test Atom</a> (image/jpeg)</p>
        <p><a href=“http://v.seesmic.com/flv/FOO.flv”>Test Atom</a> (video/x-flv)</p>
        <p><a href=“http://creativecommons.org/licenses/by/3.0//us/rdf”>Creative Commons Attribution</a>
        </p>
    </div>
</body>
</html>

Right now we think there is a bug in how Tigase handles this (well, actually since it’s not generating the body there is a bug *somewhere*), so I can’t show you a live example :( but as soon as the dev guys fix it, or tell me what I did wrong, I’ll make another post.

You can find the XSL template I’m using here

Update: sure enough, Bart demostrated it working on his test server so I dug deeper and discovered that the Java XSLT processor is *much* more pickier than xsltproc about errors. One of the helper templates was missing but it was never called so xsltproc just gleefully went on it’s merry way where as Java’s tossed an error and just refused to do anything more. So now Tigase is generating <body></body> *and* <event><event> payload data!


Creative Commons Attribution-ShareAlike 3.0 United States
This work by Mike Taylor is licensed under a Creative Commons Attribution-ShareAlike 3.0 United States.