on my (ab)use of Radio Userland
Dave notes that UserLand's RSS PageRank is now zero. Google doesn't follow redirects when calculating PageRank. My old PageRank was 7/10. Now it is zip. I have also found that Google isn't updating the calclation that often. They must be batching it each quarter. I have seen lots of sites stuck at zero even though they are popular. [John Robb's Weblog]
Google does follow redirects. However, and here's where you're losing it, for PageRank to follow they have to be 301 Moved Permanently redirects. Google couldn't give a shit about Dave's attempt at an RSS redirect, and 302 Found redirects are temporary, so why should the index update anything?
Final lesson from this situation: never, ever blog at a domain that’s not owned by you. Don’t blog on your employer’s site, don’t blog on your blogging application’s site — make sure your blog lives (and stays!) on your own domain.
The things of this world are short-lived, die and rot. But be prudent and plan to take your stuff with you when you go. Technically that means use an e-mail address where both sides of the @ are yours. When you use someone else's site, whether pages.prodigy.net or radio.weblogs.com, you're renting. Eventually, you'll want to move out of your parents' house and stake a claim of your own.
Within the channel element, link is "The URL to the HTML website corresponding to the channel."
Within the item element, link is
The URL of the item.
Within the item element, guid is
A string that uniquely identifies the item.
What is an item?
An item may represent a "story" — much like a story in a newspaper or magazine; if so its description is a synopsis of the story, and the link points to the full story. An item may also be complete in itself, if so, the description contains the text (entity-encoded HTML is allowed), and the link and title may be omitted. All elements of an item are optional, however at least one of title or description must be present.
[INSERT MORE HERE ap example, nyt example, me]
But then we have this clarification:
link should be used only to link to the article being described by the post. Here's an example. In the example you'll find an item with 1) a title, 2) a link, 3) a description of the link, and 4) a guid, which is not a "permalink." Why? Because
If the guid element has an attribute named "isPermaLink" with a value of true, the reader may assume that it is a permalink to the item, that is, a url that can be opened in a Web browser, that points to the full item described by the
So, since thing described by my item element is not this, there is no permalink? That's a bit confusing.
And what it boils down to is that some vociferous people find it obscenely difficult to communicate effectively.
This comment is not productive, and, since I don't care to find the documents backing my memory, may be wrong.
In 2001, the UserLand RSS version was 0.92, and all elements of item were made optional. Specifically, title and link became optional. This is the version of RSS that I became acquainted with from using Radio. The earliest sample I have is this one from April, 2002.
On March 12, 2002, the Radio application was enhanced to allow users to specify a title and a link for each item. Prior to that enhancement, users could specify only the description (and category); everything else was programmatically generated.
The link element that users specified was not necessarily the same as the URI for the HTML rendering of the item. It could be any URI, though in practice it was either the URI of the item's rendering, or of some thing referenced by the text in the description.
Radio stuffed this user-specified link into the RSS link element, and the title into the RSS title element. In rendering the HTML version, the title was styled, and the link added. Here is a sample 0.92 file from June, 2002. Some items have no title, while others do. Each item has a link.
This change to Radio caused a problem. Before, the aggregator could assume that the link element referred to the HTML version, and could act in a particular fashion based on that assumption. Making the link element user-editable invalidated this assumption.
This could be resolved in two ways. First, Radio could use the specified link only in the HTML rendering, while using the HTML URI in the RSS link element. Alternately, realizing the need for a means of identifying the item itself, the RSS specification could be revised.
The second option was chosen. This additional element is the guid.
Yesterday I wrote about a means of causing two RSS feed consumers to update their subscriptions list, and about a means of causing web browsers to load another page. This is not the best way to do either of those things. However, it may be the optimal way.
The optimal way is that which works best given certain constraints. In this situation the constraint is two-fold:
- end-users are unable to modify the server configuration (by placing directives within a .htaccess file)
- This is the closest thing to a meta refresh workaround for RSS aggregators.
There are downsides to these methods. The downsides of the meta refresh element are that
- it is bandwidth intensive, and
- machines do not update themselves
By the latter I mean those like our friend Google, which will not update its index, and so PageRank will be lost. Some machines simply do not follow that element, and are stuck wondering where you went.
The downsides of the attempt to redirect RSS are many.
- It's not RSS.
- Only Radio Userland and NetNewsWire do anything with that file, so
- people who read your feed in other aggregators will never know you moved.
- It's a machine-readable format that means nothing to machines, and is barely comprehensible for humans.
- It requires extra effort on your part.
So what should you do? If your readership only uses Radio Userland and NetNewsWire, then that fragment of XML is fine. If they don't, then a politely worded note in the RSS must suffice — perhaps in combination with a polite request to Userland to be considerate of others.
modified system.verbs.builtins.radio.weblog.render (called from macros.viewWebLog) to remove some items that should properly be in the #itemTemplate.txt file.
- in itemsText, empty anchor (a) element at start of item
- in the bundle which sets itemTitle, assigning a class to the weblogItemTitle is nice and all, but don't you think that shouldn't be in the script?
- system.verbs.builtins.radio.data.website.["#tools"].listCategoriesForPost, is compiled code, so I can't edit it. However the div enclosing the category list should be removed, allowing that list to be formatted in the #itemTemplate.txt file
also made some changes to the #itemTemplate.txt file
- removed extra and <br /> elements.
- the span enclosing the datestamp should be a paragraph
Userland provides site hosting and updates for Radio Userland users on a subscription basis. The cost of the first year of this subscription is included in the price of Radio. If the subscription is not renewed, then two things will happen:
- The Radio Userland program will no longer update itself.
- Files on radio.weblogs.com will be removed.
If you decide not to renew, and will continue publishing from another location, there are some things you should do to prepare the world at large, to notify your readers of the change. Readers come in all shapes and sizes. Some of them are human, others are machines. Humans, as a rule, are somewhat more flexible than machines, and can be notified in a plethora of ways. Machines like things to be just so. Not only do you have to speak their language, but you have to be grammatically correct.
Since we're speaking of a web site here, the machines in question speak the Hypertext Transfer Protocol (HTTP), and may understand HTML and RSS. This is good, because you won't be able to use an HTTP Redirect on radio.weblogs.com, with all that implies.
For the HTML version of your site, edit your template to include a
meta element, then re-publish everything. This will cause some machines to load the new location. This is an example that will cause the browser to load the new location zero (0) seconds after loading the original location.
Joe Friend passes on a UserTalk macro which will customize the
<meta http-equiv="refresh" content="0;url=http://weblog.bluepenguin.us/0106188/index.html">
metaelement for each page:
<meta http-equiv="refresh" content="5;url=http://www.newsite.com/<%local (pta = html.getpagetableaddress ()); local (path = pta^.path); return (string.replace (path, ".txt", ".html"))%>">
Some machines, primarily search engines, do not pay attention to this element.
For the RSS version, there was some argument a while back about a method for using RSS to inform feed consumers of a change in the status of an URL. There was no real agreement on what to do about this, but discussion died once Dave Winer wrote something for Radio Userland. Due to the lack of consensus, this has only been implemented in Radio and NetNewsWire. This does not reduce its utility, since at least a subset of your readers will be moved to follow.
The following procedure is not intended to be a comprehensive guide to site migration. While it assumes that you will not use Radio to update your non-Userland-hosted site, the differences between this and simply using another host for your Radio-generated site are minimal.
- Edit your template to include the
metaelement mentioned above.
- Write a farewall post for the Userland-hosted site.
- Hand edit your rss.xml file to point to the new location.
<?xml version="1.0"?> <redirect> <newLocation>http://weblog.bluepenguin.us/0106188/index.xml</newLocation> </redirect>
- Upstream everything to radio.weblogs.com.
- Turn off the Radio.
Any questions? This method is not recommended if your readers do not use Radio Userland.