Monday, September 21, 2009


(The below post is relatively technical)

Over at Dave Winer's blog there's work being done to determine how to best discover RSS feeds and keep them up-to-date.

Mr. Winer has defined a solution which consists of the following:

- Create a web service with an HTTP-to-DNS API
- Use the above to enter in a unique subdomain a TXT record into a whose sole string is the url for the feed
- Also create an HTTP proxy service that exposes the TXT record to a web browser, when such browser is requests the subdomain

This works, except that TXT records are definitely sub-optimal for this. One should use other types of records more suitable for this, such as NAPTR records. Furthermore, if you have a .tel domain, whether the final implementation uses TXT or NAPTR records, you're already in great shape because you've already got all the tools necessary to support this.

Regarding TXT vs. NAPTR, I suggest using NAPTR records of type 'x-rss' (and also 'x-opml') such that a DNS query to (for example) will look like this:

100 100 "u" "E2U+x-rss:http" "!^.*$!!" .

The DNS query to get the above is:
dig +short naptr

A NAPTR record has the following advantages over a TXT record:

- It's got an enumservice type ('x-rss:http') which allows clients to understand what it is ('x-rss') and how to access it ('http'). TXT records don't have any of that, which can lead to much confusion unless you structure them accordingly (i.e. have multiple strings, the first one being the type).

- It's got an order and a preference (both 100 in the above case), which allows you to specify multiple ordered URLs for the same feed, and allows you to have multiple feeds in the same subdomain: each unique feed has the same unique order number, and for each unique feed you can have multiple urls ordered by preference. Note that I didn't invent this usage, it's standard for NAPTR records

- The URL that you see in the NAPTR record is actually called a 'replacement', because that's what it is. It 'replaces' the request made, and is in fact a fully qualified regular expression. In the above case, we're saying "please replace the whole query with ''. The actual request made was for ''. That request is now replaced with the give URL. Because this is a regular expression, you could have been a lot more specific with the replacement if you wanted to

Since I'm using a .tel domain, I've got access to an API. The PHP code to create this RSS entry in the DNS is below:


$naptr1 = array(
'order' => '100',
'preference' => '100',
'services' => 'E2U+x-rss:http',
'flags' => 'u',
'regexp' => '!^.*$!!',
'owner' => '@',
'profiles' => '_all_',

$config = array();
$config['login'] = '****';
$config['password'] = '****';
$config['wsdl'] = 'my.wsdl';
$domain = '';

$client = new Telhosting_client($config);
$client->store_record($domain, 'naptr', $naptr1);

Can't be much simpler than that...

Friday, September 04, 2009

Apologies to my iPhone users

Well I'd like to apologize to the users of my iPhone apps, and Superbook.
I know that there's a critical crashing bug in version 1.0.1 as it currently stands on the app store. I'm sorry that I missed that bug when testing the app. It triggers when you're updating a contact record and change its type (say from "Skype IM" to "Skype Voice").
As soon as I was told of the crash, I fixed it. It's a simple 3-line change. I re-uploaded a new version, 1.0.2, to the app store right away. At that time Apple added a new feature when uploading apps, called "Keywords". You can now add keywords to your apps for better searching on the app store (that's assuming search works properly, but it doesn't). Well, I added a few keywords like ".tel, telnic, unified messaging, AIM, Skype". Things that I thought were relevant.

Fast forward to today, which is 21 days after I submitted my 3-line change. The app still isn't approved. Of course I had zero feedback from Apple. I sent emails, and I know that some of my users sent emails as well. So now I have to figure out why in the nine hells it's taking so long, without any feedback. Welcome to the world of the Apple AppStore.

I also have a big update to Superbook will a bunch of new features that's also in limbo. That one has been lingering for over two weeks. So I decided today to reject my uploaded binaries, get rid of the keywords, and re-upload them. This also reset the clock for approval time, so in the best of cases, it will have been one month to get a 3-line change through the Apple process.


Sorry my dear users, but all I can say is "it's out of my hands".

Update sept 5 2009: Less than 24 hours after I wiped the keywords and resubmitted a new binary, Apple approved But Superbook is still in the process.

Moral of the story: Don't even try to guess what Apple is doing, I don't think Apple even knows itself.