Quoderat

I’ve noticed that Slashdot has started to include text ads in their RSS feed much more frequently, and I’m considering unsubscribing. I have no moral or ethical objection to text ads in RSS feeds, but this is the first time I’ve run up against that many text ads all in a row, and I find them ugly and rather annoying (on web pages, there’s more going on, and text ads don’t get in the way so much).

So, am I one of those people, often flamed in Slashdot comments, who expects something for nothing? How is Slashdot supposed to make money from providing an RSS feed to freeloaders like me? There are two reasonable answers to these challenges:

1. Slashdot strips links from their RSS feed, so if I want to follow a source or read comments, I have to visit the Slashdot site (and see their ads) anyway; and

2. in business, it’s OK to be selfish — I look for what I want, the other side looks for what they want, and if we cannot find any common ground we just wish each other luck and walk away. If I want an RSS feed without text ads, it’s OK for me to go looking for one; if Slashdot wants to put ads in their feed, it’s OK for them to do so. If there’s no common ground, then I simply stop reading Slashdot.

Of course, from an entrepreneurial point of view, that still leaves a problem: how can people make money directly from fulltext RSS feeds? Indirectly, of course, you can use them to promote yourself or your business, but what if the feeds are your business?

[More updates from comments.]

[Update: many more results, collected from comments. It looks like nearly every feed reader can handle at least HTTP basic authentication, which is good news for people planning to use RSS and Atom in government or enterprise.]

I’ve uploaded a small, static RSS file at http://www.megginson.com/test/blog.rss. The file is valid RSS 2.0 (or 2.01, if you prefer), and is served with the MIME type application/xml.

Here’s the kicker — it’s password-protected, using HTTP basic authentication. The username and password are both “guest”. Can your RSS software or webapp read this feed? Here’s what I’ve tested so far:

Liferea

Prompts for a username and password, and stores the password on disk as clear text.

Bloglines

Reports no feed found. However, will read the RSS file if the username and password are encoded in the URL, i.e. http://guest:guest@www.megginson.com/test/blog.rss

FeedValidator

Reports a 401 HTTP error (authorization required). Strips the username and password from the URL if they are provided.

Here are results gathered by others and left as comments for this posting:

CaRP

Antone Roundy reports success when the configuration line CarpConf(’basicauth’,'guest:guest’); is included. I am not certain if that line would apply to all feeds, or just to this one.

FeedDemon

Bill de hOra reports success both with this sample and with password-protected https feeds at his workplace.

RSSBandit

Dan Sholler reports success.

Sage

Tim Howland and John Cowan both report success, since Sage uses the browser’s built-in authentication support. M. David Peterson points out that anything built on top of Mozilla/Firefox or MSIE should work.

NewsFire

Peter Lacey reports success.

Thunderbird

Christof Hoeke reports success.

NetNewsWire

Ryan King reports success.

SharpReader

Roland Kaufmann reports partial success (with the username and password embedded in the URL).

iTunes

Robert Sharl reports success (though iTunes reports an error due to the lack of an audio enclosure).

Opera

Rijk van Geijtenbeek reports success.

KDE Akregator

Douglas reports success.

I’ve decided it’s time to figure out if aspect-oriented programming is worth, well, figuring out.

So far, nearly everything Google can find for me about AOP is positive — glowing, even — and that makes me nervous. Real change is supposed to be painful: even today, when object-oriented programming has become dominant, it is easy to find critics; XML had, and still has, many detractors; and any self-proclaimed guru standing in a Starbucks line can tell you what’s wrong with HTML and the web before the barista has time to finish making a cappuccino.

Does the lack of criticism mean that AOP is practically perfect in every way, or simply that people don’t care enough to pick it apart? After reading some online introductions and studying the AspectJ syntax and tutorials (with their seemingly endless trace and log examples), I can see how the approach might have some benefits, but I’m not convinced that the benefits outweigh the potential code obfuscation.

In fact, one of the few critical pieces I did find, a two-page University of Passau paper entitled AOP considered harmful (the paper later spawned a $250 business research paper), compares AOP with the notorious GOTO statement from early procedural programming languages, attacked by Dijkstra in his classic 1968 letter Go To Statement Considered Harmful. In addition to GOTO, AOP also reminds me a bit of C macros, another cause of confusing, hard-to-maintain code.

I’d be interested in comments from people using AOP (AspectJ or otherwise), as well as pointers to other sources that are not simply hyping the movement. Does AOP work for you? I’m skeptical, but I’m not willing to dismiss it yet.

A geocoder is a system that takes a street address and converts it to an (approximate) latitude and longitude for use in GPS navigation, online cartography, and similar applications. MapQuest has a nice online tutorial for different geocoding algorithms, with illustrations.

A new, extremely simple geocoder has just come online for Canada, named (unsurprisingly) geocoder.ca. The app includes both an HTML interface and an XML (and HTTP) API. Here is an example of a GET URL for a simple API call to geocode 1 Lindbergh, Ottawa, Ontario:

http://www.geocode.ca/?addresst=lindbergh&stno=1&city=ottawa&prov=ON&geoit=xml

Here’s the XML document returned in the HTTP response:

<?xml version="1.0" encoding="iso-8859-1" ?>
<geodata>
        <latt>45.3358320000</latt>
        <longt>-75.6864510000</longt>
</geodata>

It’s also possible to send your own transaction ID and have it returned in the XML. If I append “&id=foobar” to the above URL, I get this back:

<?xml version="1.0" encoding="iso-8859-1" ?>
<geodata>
        <latt>45.3358320000</latt>
        <longt>-75.6864510000</longt>
	<id>foobar</id>
</geodata>

Finally, like many REST applications, this one has its own ad-hoc error-reporting scheme:

<?xml version="1.0" encoding="iso-8859-1" ?>
<geodata>
        <error>
                <code>004</code>
                <description>Specify a Canadian province two letter code.</description>
        </error>
        <latt>
        <longt>-

</geodata>

This is another great example of how plain XML and HTTP make it easy to provide a public API.

The European Commission has voted against software patents overwhelmingly. Only a few months ago, things looked desperate — Poland was the only European country with the courage to keep on fighting — but now the technology world can celebrate its own modest Victory in Europe day.

If Europe had fallen, it would have been impossible for Canada and other little countries to stand up against combined European and American pressure.

Thanks, Europe.

I threw together a very short demo of a partial flight route — the low-level airway V316 from Ottawa to Sault Ste. Marie — overlayed on Google Maps using the new Google Maps API (I’ve also mentioned this in a posting on my flying blog). Each marker on the map is a navigation transmitter or intersection. This could look an awful lot better, but it’s still more interesting than the default Hello World app.

Most of the work takes place in the google-map-demo.js JavaScript file, which is currently 38 lines long including comments. Note that it is table-driven, so it would be easy to modify it to run from a database or XML file. The google-map-demo.html HTML document runs my JavaScript showMap function on load, and contains a placeholder div element with the id “map”. The google-map-demo.css CSS stylesheet sets the dimensions of the div, draws a border, and makes the background white.

This is pretty simple stuff, but it’s a fun way to waste an hour or two on a holiday weekend. There’s a lot that could be done to make this look better, such as inserting frequencies for navigation aids and using custom marker icons.

In his obit for service-oriented architecture (SOA), Sean McGrath draws lessons from the demise of WS-*. Here are what Sean considers the key characteristics of something that might actually work:

• The noun/verb inversion in REST
• Temporal decoupling
• A “lets get real” approach to transactions
• Purpose-agnostic data representation
• An awareness that Object-oriented integration does not work in the large even though it works great in the small.

Read his post for links and more information.

I find the last point especially interesting. OO works well for developing many types of interactive applications, but maybe that’s just a fluke, and its principles are not applicable to the world at large. I’ve already mentioned that I find OO a poor fit for database-driven webapps, even though I consider myself primarily an OO developer. The real world doesn’t fit nicely into class hierarchies (yes, I know about aspect-oriented programming; in fact, I remember something similar for LISP called “facets” from late 1970’s or early 1980’s AI literature).