B10[mg]

There we have it. Now you can use your webcam (and microphone, or so I believe) with your chat client. Wow, amazing. While MSN Messenger and Y! Messenger have supported this since the beginning of times, now Google joins. Good.

But it get's better! It works from within your gmail box. So it's video conferencing through a website! Again, nothing new. Seriously. A website like imo.im supported multi-IM with cam capabilities already.

Have you ever heard about imo.im? Ever read about it in the news? I most certainly have never seen news reports on that service. But once your name is Google, every fart is interesting and so you must read about this non-original feature in their beta application everywhere.

Do we really need to read about this everywhere? It seriously sickens me. Look at the list of sites all blogging/reporting about this insanely stupid new feature: Cnet, TechCrunch, LifeHacker, ars technica, Gizmodo...

and even reuters and nu.nl (a rather big Dutch news website)

Seriously, STOP THE HYPE.

google, imo.im, news

Caching is the art of storing a certain file for easy retrieval later, or at least, that's how I see it. The benefits for the user are clear: whatever you're caching makes the process of requesting it another time later a lot faster.

Search engines offer you cached versions of webpages as well, and according to CNET, Google offered this since 1997 (and the others probably introduced it around the same time).

To me, search engines take the wrong approach and courts all around the globe seem to find it a difficult question as well. When is someone infringing a copyright? After Google losing lawsuits in Belgium over indexing news articles and in Germany over image search "caching", today a US court ruled in favor of Yahoo! and Microsoft's caching.

Besides the fact that Gordon Ray Parker probably has nothing else to do than suing, and besides the fact that he probably fully knew how to opt-out, this lawsuit makes me very unhappy.

Why is it so bad when the big search engines are allowed to cache your content? It's quite easy, because they're making money with your content. The whole idea behind caching webpages to me sounds like an attempt to have the visitor stay at the search engine's page a little longer, and thus more chances that he's going to click on an ad (= cash).

The fact that they have an opt-out mechanism, based on a draft that expired in 1997, doesn't make it any more logical to me that it's allowed to "steal" data for profit.

Let's scale it down. Every webmaster/blogger has at some point noticed that his/her text was taken completely out of context and dumped on some other blog, surrounded by nothing but ad-sense ads. That's truly annoying. The operator of that site hopes to gain some traffic from SEO and hopes for people to click on some links (which they'll do, for the copied text makes no sense).

According to the ruling, that is all ok now, unless you specifically tell the crawlers that they can't do that. So now the burden is on the shoulders of all the webmasters in the world. Configure your robots.txt correctly. Not that it helps a lot, for the annoying blogs mentioned above probably ignore it to begin with, but ok. Why should everybody with a website explicitly tell all potential crawlers to keep their filthy claws of their property? Why can't there be a standard where you specifically set up a document that describes what crawlers are allowed to grab/cache and do whatever with as they see fit? Because it'll destroy Google, Yahoo! and Microsoft (and other search engines, of course). But who really cares?

Again, $(big companies that claim to be non-evil)++ vs $(rest of the world)--.

Sad, very sad. Maybe I should start scraping Google's results, but oh no, the don't allow you, nor does Yahoo!, nor does MSN

cache, google, yahoo, microsoft

I don't often read the "dagblad van het noorden" website, but today I noticed a news article around the crazy PVV . They find it insane that the poorest people of the Netherlands can get money to buy a flatscreen tv or something (still have no clue what they're exactly against).

Anyways, when opening the webpage, I saw this (click to enlarge)

An overlay asks you to fill out a survey. If you participate, you could be the winner of the Philips LCD TV, yay. Ironically, this overlay covers the title of the article ("PVV wil verbod op flatscreen via bijstand").

fail, fun, philips, flatscreen, groningen

Net::OpenID::Consumer has just been released to CPAN (it was on BRADFITZ's svn repository for a while), which enables you to handle OpenID 2.0 logins (and since Brad is listed as author of the 2.0 protocol , I trust it's a solid module :)

Since Net::OpenID::Consumer now handles OpenID 2.0, Catalyst::Authentication::Credential::OpenID does too (thanks to ASHLEY (and yes, "ashley is a boy's name")).

This is good news, 'cause Yahoo! only accepts OpenID 2.0. So from now on, all Yahoo! users can login to your application and that without a lot of code (thanks to the awesome Catalyst Framework).

After implementing it, I ran into the horrors of the Yahoo! implementation. They are very strict and when you screw up at a certain point, they'll greet your users with a lovely message:

Warning: This website has not confirmed its identity with Yahoo! and might be fraudulent. Do not share any personal information with this website unless you are certain it is legitimate.

I tried to lookup what caused this and came across a good and quite detailed solution The only bad thing about it: it didn't work for me.

After messing with it for way too long, I noticed that my return_to URI was redirecting Yahoo! (so what?), so they ignored the Yadis header and thus raising the error.

To fix this in Catalyst, you must make sure you have the following things done:

1. Create a yadis.xrdf (see the template)
2. Have Catalyst return the right Content-Type header for the file (if you're using Catalyst::Plugin::Static, check the POD!)
3. Inserted a X-XRDS-Location header for at least the return_to URL
4. Have Catalyst return a 200-response code on the return_to URL

I was using code like this:

    my ( $self, $c ) = @_;

    if ( !$c->authenticate({}, "openid") ) {
        $c->flash(error => "OpenID login failed");
    }

    $c->res->redirect( $c->uri_for('/') );
    $c->detach();

FAIL! Don't redirect (or redirect with a meta-refresh, or javascript).

Since this took me hours to figure out, I hope this blog post makes your life a little easier.

perl, catalyst, openid, yahoo, xrds, fail,

After I released Catalyst::Authentication::Credential::Flickr version 0.02, FAIL messages poured in from CPAN testers (well, to be more precise, from one tester with multiple test machines).

The error the tests failed on was:

No _parse_* routine defined on this driver (If it is a filter, remember to 
set the Parent property. If you call the parse() method, make sure to set a 
Source. You may want to call parse_uri, parse_string or parse_file instead.) 
[XML::LibXML::SAX::ChunkParser=HASH(0x83dab48)]

I was not able to reproduce the error and thus mailed the CPAN tester (ANDK). Not much later, Andreas informed me about the installed versions of several dependencies but even with those exact same versions, reproducing the error was impossible.

On closer look, it turned out the order of installing XML::SAX parsers really mattered, for that makes up the order of them in XML/SAX/ParserDetails.ini

As it turned out, ANDK had XML::LibXML::SAX::ChunkParser installed last and thus that module became the default parser module for XML::SAX. The author of that module is aware of this bug, and patched it in a newer release, but that didn't help me much.

I've spend way to much time debugging this, so I figured it'd be nice to at least write down the solution to this: erase the XML::LibXML::SAX::ChunkParser part out of ParserDetails.ini.

Since XML::Simple already has some checks for faulty modules, I've asked the author to add this module as well, so we can safely require a new version of XML::Simple in our Makefiles and bypass this bug.

XML::SAX, XML::Simple, XML::LibXML::SAX::ChunkParser, CPAN