Nerd Life

When looking at the sitemaps protocol which is now endorsed by Google, Yahoo and MSN, I can't help but crying about how obscure the documentation is, especially for the <priority> element.

Please note that the priority you assign to a page is not likely to influence the position of your URLs in a search engine's result pages.

Okay, so what's the point?

Granted that setting all priorities to 1.0 will not make the urls rank higher than urls from other sites. But we're talking about position of URLs here, not sites.

Sometimes, the same site appears multiple times in search results, with different pages/urls. In that case, if priority doesn't influence which URL comes first, compared to which other comes second, then what's the use?

For example, on a blog, the same info can be found on a post's permanent url, on the homepage, on the category page, on the archives pages, the RSS feed, etc.

Sometimes the search will return several of these locations. If the priority can't be used to tell that the permanent url would be the best choice to put first, then... I don't get it! |-|

Does it mean that priorities are only used to determine what gets crawled first? If it does, then it means that maybe the 100 top priorities will be indexed and the others won't! So the top 100 may appear in search results and the other may not!

Present vs. not present! That's what they call "not influencing the position'?

Again, if it doesn't do that, then what does it do?

All I can think of at that point is the priority being an alternative to <changefreq> : a site gets a certain number of reindexes a day, and high priorities pages will be refreshed more often that low priority pages.

That would comply with the definition of that <priority> does NOT do...

But then... it doesn't make sense with what it is *supposed* to do:

it only lets the search engines know which pages you deem most important for the crawlers.

Or by "most important", are we supposed to understand "most frequently updated"?

I really wonder who it helps to have that spec being so obscure... :>>

In yesterday’s “Daily Source Code", Adam Curry is talking about his meeting in Redmond with the Windows Media Player team.

Adam says he can’t tell anything… but what else could this probably mean than Windows Media Player supporting podcasting – or “blogcasting” as they like to call it in Redmond ?

What could Microsoft possibly add to get their Media Player ahead of iTunes? Video? No way: iTunes has had that for even longer than the iPod video.

If I was Microsoft (yeah, right :>>) I’d definitely add all podcasting features you can find in iTunes and I’d add this little extra: BitTorrent distribution! (Or any other P2P distribution method if I had a political/licensing problem with BitTorrent…)

Today, independant podcasters can easily put their shows online, but as soon as they get popular, they face a huge problem: bandwidth!

The current podcasting architecture relies on a central server for each podcast and independant podcasters just can’t afford the bandwidth it’s going to take. And it only gets worse with video-casting.

Right now they have no alternative other than paying the bills and financing them by adding advertisements to their shows. A peer-2-peer add-on to the architecture would change the deal significantly. We all know how large files get distributed easily that way.

Of course the risk is for the system to be hijacked in order to illegally distribute copyrighted material… This is why Apple hasn’t done it in the first place. Will Microsoft have the guts to do it? Hum…

Does Microsoft only need to do something like this? Well… yes… sort of. They’ve lost the leadership in digital contents already and they’re losing a lot of momentum too. Besides, they have finally realized they needed a damn good IE7 after swearing there would never be a new browser after IE6… Now they realize they need a damn good new Media Player…

Can’t wait to see what’s in it!

Today, I've got this massive stack of clothes to iron... bleh :(

To make the experience a tiny little bit more pleasant, I'm listening to every podcast on my iPod I hadn't listened to yet...

Great time to catch up with all that stuff... but great frustration too!

A typical podcast has an average length of 15 minutes. And when the iPod is done with playing it, it just goes back to the main menu. Yes, that's the MAIN menu, not the podcast feed you where in, not the podcast menu either! It's all the way back to the main menu!

So you need to drill down into the podcast menu again and then into the feed you were listening too, select the next podcast you want to listen to and then, finally, you can continue to listen...

Wouldn't it have made sense for the iPod to automagically playthe next episode in the feed I was listening too!? Isn't the whole podcast concept somewhat supposed to mimic a radio with better programs? Do you need to click on your radio in order to listen to the next show?

Apple seems to have thought this through... at some point... but only halfway I guess: you can actually press play when a podcast feed is selected and the whole feed will get played. But in this case you'll suffer 2 major problems:

• You'll listen to the feed in reverse chronological order. And you'll hear feedback on the previous episode before you hear the referred to episode! :(
• You'll listen to everything, including the episodes you've already listened to before...

This second point is something else that has been bugging me for a while: there's no way you can see on your iPod what episodes you've already listened to and which ones are new.

Each episode definitely needs a 3 state icon in front of its title, indicating wether it's unplayed, partially played or completely played.

Today I thought it was time for me to catch up on Atom and add support for this format to b2evolution.

Okay, done. Here's my Atom 0.3 feed. And it validates too.

But I had to leave out a link to comments as well as my categorization! There's no support for these in the spec yet. What a shame! :no:

And finally, the biggest frustration: checked out my feed in the popular SharpReader aggregator... and it turns out it doesn't support "multipart/alternative" content. Bleh! >:XX So I had to leave that out too...

So at least, we have b2evolution supporting Atom in croncrete terms now... but if you ask me, RSS 2.0 is still the most useful syndication format! :roll:

Once upon a time, there was a company called Netscape who was investigating a new market: portal sites and content syndication. The idea was simple: a variety of websites produce relevant content in a (nearly) continuous flow. Portals would be designed to aggregate news and content from those sites and present it to the user all in one page...

Thus, Netscape invented a format called RSS, which stood for "Remote Site Syndication". This spec allows content producers to publish their news/content in an "RSS feed" (an XML based document) and content consumers to periodically check those feeds for updates.

When Netscape lost interest in developing portals, they abandonned their original (and complex) RSS 0.9 spec as well as their efforts in creating a more appropriate and simpler version. At that time, UserLand picked up the simpler 0.91 spec and applied it to its blog tools. RSS had become "Really Simple Syndication".

Today, the blogging community still uses RSS extensively: every (serious) blogger publishes an RSS feed of his posts and readers aggregate all their favorites blogs' feeds in an aggregator. This, of course, makes it more convenient to check for new posts daily on all your favorite blogs...

b2evolution is an example of a blog tool used to publish RSS feeds. SharpReader is an example of a program used to aggregate RSS feeds.

Read more »