T Bryce Yehl: Bryce's Web Services Channel

Moving

Mon, 04 Nov 2002 20:15:07 GMT

I'm finally taking the plunge and switching to "MT". I'm not going to bother importing this weblog, at least not initially. Too much work for too little benefit. My archives can stay here indefinitely.

My new home page and weblog. Feeds are available in RSS 0.91, RSS 1.0, and RSS 2.0 flavors. I'm not going to set up RSS redirects. I don't like Userland's solution because any aggregator that doesn't understand the format will barf on it. HTTP 301 redirects are better supported, but I don't feel like reconfiguring Apache to allow .htaccess files.

For the couple of people that subscribe to my category feeds, I'll get around to re-creating those eventually. Stay subscribed to the current feeds and wait for an update.

Pingback Follow-up

Tue, 08 Oct 2002 06:14:50 GMT

The other day Ian Hickson dropped by and added a comment to my post calling for a Pingback Retrieval API. My response is that the Radio community loved Pingback, but I still don't see any implementations for Radio users.

Having a Pingback Retrieval API, and encouraging the creation of stand-alone Pingback servers supporting that API, would accomplish several things:

Random CMS can integrate with Random Pingback server. The end-user is empowered to choose whichever Pingback server best suits their environment (Perl, ASP, Cobol).
Provides a clear path for certain classes of CMS, especially client-based tools like Radio, to integrate Pingback. The CMS folks can focus on integrating pings with the CMS instead of having to re-invent the wheel by creating yet another Pingback server.
Third-parties would be able to provide Pingback services to end-users.

The Pingback Retrieval API doesn't require many methods: Register, List, and Clear would be enough. Everything else is an implementation detail that can be left to the developer. Better implementations might provide a web interface for managing pings and offer additional services, like ping-forwarding via email/RSS/Trackback.

If you build it, they will come...

I'll put my money where my mouth is: Add a Pingback Retrieval API to the official spec and I will commit to building a reference implementation and hosting it until such time as it can no longer be supported by my web host.

Newz Crawler, Part III: Living with Newz Crawler

Mon, 07 Oct 2002 04:41:16 GMT

On the whole, Newz Crawler is vastly superior to Radio's aggregator. It's fast. It's organized. It's fast. Fast fast fast. I have been using "myRadio" to impose some order on top of Radio's aggregator. I use Mozilla's "Bookmark this group of tabs" feature to load all of my myRadio pages at once, and walk away for a few minutes while it churns...

Speed is good.

I also like that it allows me to quickly see which feeds have updated. Sometimes I'll do a scan, see that none of my important feeds have updated, and move on to doing something else...

I'll probably register it once my trial expires, in spite of my aversion to nag-ware.

What I don't like:

Sometimes it marks unchanged items as unread. Two of my feeds consistently display all items as unread.
Weblog client encodes quotes, breaking all hyperlinks. I fired up "tcpTrace" and compared against "Pocket Blog" just to be sure that this wasn't an issue with Radio.
Weblog client doesn't support the "MetaWeblog API". No titles, no categories, and don't even think about "liveTopics".
Weblog client doesn't have spell-check. It is so easy to integrate Word's spell-checker, and there are so many inexpensive ActiveX/COM spell-checkers, that it's almost inexcusable not to offer that functionality.

Newz Crawler, Part II

Sat, 05 Oct 2002 20:24:55 GMT

The .NET Guy points out that Newz Crawler nags because it's not registered. I knew that, but the nagging is notably pervasive and annoying.

It can be a pain to trigger scrolling on the Channels pane during drag-n-drop.

Most operations occur in-memory, if Newz Crawler crashes you lose whatever has happened during that session.

Doesn't respect system locale settings for dates.

Newz Crawler, Part I

Sat, 05 Oct 2002 03:20:20 GMT

To blockquoteth myself:

The only thing holding me back is the aggregator. I like the reverse-chronological view, the grouping functionality that "myRadio" provides, the ability to retain items in the aggregator indefinitely, and of course, the weblog integration.

I'm giving Newz Crawler a try, and initially posted this entry from it.

Pros:

Native UI.
Feed grouping (Folders).
Folders can contain other folders.
Granular on-demand scanning -- scan feed(s), folder(s), or everything.
Weblog integration with WYSIWYG editor.
Favorites folder for storing news items for later use.
Detects items that are only a headline and link, automatically loads linked content.
Hot-key to mark all items as read (Catch-up function).
Hot-key to delete all items (Clear function)

Cons:

Time-delay nag screen on launch that requires a button press to clear.
Nag screen on close that requires a button press to clear.
Constant reminders throughout the program that it is unregistered.
Favorites folder cannot contain sub-folders.
Supports Blogger API only -- no titles, no categories.
WYSIWYG editor has some odd issues with control focus.
Puts a tagline on weblog posts.
Using Clear function will cause all items to re-appear as new in the next scan. Manually removing all items from a feed does not cause this.
Sometimes double-clicking an item will cause an infinite number of IE windows to appear. This has happened to me three times. I'm not going to double-click anything in NewsCrawler ever again...

I need some more time to play with it, see how well it handles updated and duplicated items. Overall I like it, in spite of a few bugs... but I hate to pay for any program that nags.

Radio Userland feeds still lacking (or not, my bad!)

Thu, 26 Sep 2002 03:20:02 GMT

Userland has rolled out RSS 2.0 to Radio users. RSS feeds have been silently updated to incude GUID elements that contain permalinks. The GUID goes not have the isPermaLink attribute set to True.

WTF?!

My bad, the spec says that isPermaLink=True is the default. Thank you, Justin. I can't remember if it always said that...

Building a better TrackBack...

Tue, 24 Sep 2002 01:37:31 GMT

Ian Hickson: Pingback 1.0. "The best thing about this idea is that unlike similar schemes like TrackBack, it is totally transparent to both users." [via dive into mark]

The concept is simple, the tech is easy (XML-RPC), and the spec is well-written. I like it, except for one thing: it assumes that the Pingback server will be integrated with the CMS. That's not going to be the case with static tools like Radio, they'll need stand-alone Pingback servers that can store pings until the CMS retrieves them. It's not a huge problem, but it would have been nice if they had spec'd an API for that.

Fri, 13 Sep 2002 19:37:51 GMT

Comment Monitor provides a a simple method of tracking comments on a Radio weblog.

Wed, 11 Sep 2002 00:12:04 GMT

Walking the walk...

Bah.. trying to blogwalk. Using my T-Mobile Pocket PC. T-Mobile's proxy server barfed the first time. Better to use Pocket Blog. [Frank McPherson]

I've been trying to hide the fact that I'm a total smart-ass from my weblog readers, but when I read that first sentence my initial thought was "Don't trip." "smile-tongue" I like Frank, my referrer logs show that he is constantly plugging "PB" in PDA discussion groups whenever weblogs are mentioned. Thanks, Frank!

I've decided to give "Blogwalking" a shot using l.m.orchard's proposal (Zaurus + "MT"). I have my reservations over using this particular method, but... how can I knock it if I haven't tried it?

Step one: Upgrade my Zaurus SL-5000D to the Crow ROM. The SL-5000D is just like the SL-5500 except that it only has 32MB RAM. The process was easier than I had expected, but I have encountered a problem: my Zaurus crashes whenever I turn it off following a sync.

I'll putz around with that later tonight. I can live without synchronization, Intellisync-SL sucks anyway, but for the purposes of this experiment I would prefer to use a fully functional PDA. Once I get the sync problem fixed, or give up on it, I'll tackle Apache, Perl, and Movable Type. I don't expect any problems as they are all fairly easy to install and configure.

The real challenge is: can the Movable Type templates be sufficiently tweaked to create a reasonable interface for creating entries on a PDA?

Mon, 09 Sep 2002 04:18:26 GMT

Krzysztof Kowalczyk: Give a spammer bad address.

Just found this idea: put on your web pages bogus e-mail addresses. They will be harvested by spammers and will clog their address books.

Wpoison has been doing this forever, and Googling for poison+spam provides a wealth of links. Interestingly, the author of Wpoison suspects that many spam-bots now respect robots.txt.

Mon, 09 Sep 2002 03:59:17 GMT

RadioExpress is a Radio script and bookmarklet that will post the selected text from a web page, similar to BlogThis! and ManilaExpress.

Why am I just finding out about this?

Wed, 04 Sep 2002 20:30:48 GMT

RSS 0.94 Uptake

Syndic8 is showing several early adopters of RSS 0.94. All are using the pubDate element, several have a category element for the channel, but so far only Scripting News is using GUID, without the isPermaLink attribute and without a LINK element.

My latest thought is that LINK should also have an isPermaLink attribute.

PS: Syndic8 provides all sorts of RSS statistics.

Wed, 04 Sep 2002 18:49:21 GMT

"PB" Direction

The port of "Pocket Blog" to the .NET Compact Framework is mostly on hold at this point. I find myself working around too many of the CF's bugs and limitations, which is very frustrating. I don't want the CF version of PB to degrade into an ugly mess of difficult-to-maintain work-arounds... I already have that with the eVB version.

When a new Beta is released I will re-examine the problems I am having and decide if it is worth continuing. If not, I'll wait for the full release.

In the mean time I am thinking about how to better integrate "PB" with various weblog software and APIs. The "Blogger API" and "metaWeblog API" are established standards. Pyra has been extending "Blogger", "MT" has several extensions and does not implement the full "metaWeblog API". On the "RU" front, I wonder how PB could work with "liveTopics".

Rather than shoe-horn all of this stuff into PB itself, I'm thinking of switching to a plug-ins architecture. Using the object-oriented capabilities that .NET offers, PB would provide base objects that represent a weblog post and the editor interface. Individual plug-ins would inherit and extend these objects to account for metadata required by a particular API. They would also manage communications with the server. Ideally, plug-ins would allow themselves to be extended by other plug-ins: a plug-in for "MT" would only implement functionality specific to MT, the rest would be inherited from the "metaWeblog API" plug-in.

I like this concept because it allows "PB" to grow incrementally: new APIs will not require a new release of PB and could be supported by others (particularly in areas that don't interest me, like the "liveJournal API").

Wed, 04 Sep 2002 15:21:18 GMT

More on RSS 0.94

Dave Winer pointed out that RSS has always been limited to HTTP and FTP URIs (see Semantic Differences), and that he hasn't changed it because he hasn't heard of compelling uses of other URI types.

The CMS that I built for my previous employer required the use of HTTPS, that's a real-world requirement for another URI type. I can envision uses of RSS revolving around NEWS and RTSP, but I can't really say that they are compelling or likely to occur "in the wild."

I'm still nit-picking over the use of story vs. a more generic term like item or syndicated content. Fetch Retriever can syndicate non-web content using RSS.

Mon, 02 Sep 2002 18:18:43 GMT

Not what I had in mind...

RSS 0.94 has a new optional isPermaLink attribute on the guid element. If the guid happens to be a permalink to the item being described, set this true, and aggregators may do something special with it. [Scripting News]

Ugh!

See New version of RSS found lacking and Semantic Differences.

Sat, 31 Aug 2002 18:45:35 GMT

Semantic Differences

To bitch some more... The ambiguity over LINK elements stems from changes introduced in the RSS 0.92 spec. With the RSS 0.91 spec, ITEMs were clearly intended to summarize content. The DESCRIPTION element was a synopsis of the content, with a maximum length of 500 characters. The LINK element was required and supposed to point to the full content.

With RSS 0.92, the length limitations are gone, LINKs are optional, and with Userland's RSS implementations, complete content is syndicated instead of summaries (initially without LINKs, later with ambiguous LINKs).

RSS 0.94 ought to address the disconnect created between the two previous specs and remove the ambiguities. Also, why are LINK and URL elements suddenly restricted to HTTP and FTP? HTTPS may be required for corporate applications of RSS and k-logs, but more importantly, there are many Official URI Schemes and not all uses of RSS center around Websites and Aggregators. Applications should decide how to handle unfamiliar or potentially dangerous URIs.

I'd also like to see the word story replaced with item or syndicated content, but that's just nit-picking.

Sat, 31 Aug 2002 17:58:44 GMT

New version of RSS found lacking

As promised, here's the first draft of the RSS 0.94 spec. It's a consolidation of all the specs I've written over the last two years. A few new features, listed on the (new) change notes page. Please read the roadmap to see what comes after 0.94. I'm not looking for much feedback until next week, but of course if you like it, no need to wait to say that. [Scripting News]

It's disappointing that Userland hasn't taken this opportunity to clarify the use of an ITEM's LINK element. The spec describes it as "the URL of the story", which many have interpreted as "the URL of the content in the DESCRIPTION element" (Permalink in weblog-speak). Radio, however, doesn't generate LINK elements by default and allows the user to specify an arbitrary URL (presumably to content referenced by the story).

This has been a source of contention amongst Aggregator developers, see Radio Userland Feeds Found Lacking and the resulting discussion.

Rather than address the confusion, RSS 0.94 had added a GUID element (Globally Unique IDentifier) to enable Aggregators to determine if an ITEM is new. The content of the GUID is unspecified, which will lead to more confusion. Userland's present implementation uses a Permalink for the GUID, which is probably the only way to ensure global uniqueness under these circumstances, but the reality is that Aggregators will have to assume that the GUID element will only be unique to an individual feed.

Now, the fact that GUIDs and LINKs within an ITEM contain ambiguous content is a Pain In The Ass for Webloggers that use Aggregators (ie: most Radio users). When weblogging about external content, it is proper form to include a hyperlink that points directly to the content in question (call it a citation, attribution, whatever). This should be automatic, but Radio's RSS feeds are ambiguous and Radio's Aggregator ignores LINKs.