Ben Hammersley is writing the O'Reilly book on RSS. Content Syndication with XML and RSS

The Internet is for everyone. RFC3271 Even Martians.

Need To Know 2002-04-26 presents Michael Greene's Grammy speech "The Insidious Virus of Illegal Music Downloading" turned into a rockin' Drum and Bass track. RIAA, We Love You That's a big shout to DJ C0ntaX for that one.

The England World Cup footie saga is a laugh isn't it? First it's Beckham's foot, now it's Sven's dick! Simon Barnes in the Times had it right. Ulrika-ka-ka-ka Johnsson "If she was a tennis tournament she'd be the Swedish Open"

There's a debate going on about programming approaches to Web Services that allow them to be extensible and not brittle. There's one solution that I whole heartedly support. "Use named params. Ignore parameters you don't recognise. Default parameters that are not passed". This is what we did with CGI and in that environment it just works. It allows WS developers to add extra parameters to server code later without breaking existing clients. It allows servers to drop parameters when they're no longer needed. It allows clients to call the WS when they don't have all the data required. 

But unfortunately several server toolkit implementations break if a full set of parameters are not supplied. And it forces a particular style of encoding in XML-RPC that is supported but isn't obvious in the spec. There seems to be a mindset here that equates WS programming with local object programming in compiled languages. It may even be inherent in the "Obect Access" initials part of SOAP. Dynamic Scripting languages like PHP and perl have understood this for years.

If you hard code the WS call as a fixed list of required parameters and break when they're not all there or an extra one is present, you're storing up problems for the future.

Great speech from Bruce Sterling. Viridian Note 00309: CFP 2002 Speech : "Where do you want to go today, Mr. and Mrs. America?" "Hey, I want to cruise in Steve the Dell Dude's borrowed convertible, playing borrowed MP3s!" "But no no NO, that's not what we meant! We meant, where do you want to go today, to GIVE US SOME MONEY."

Brent Sleeper writes "the core web services standards must not be subject to patent restrictions." Absolutely.

I've been trying to puzzle out an equivalent of Google's PageRank but for people instead of web pages.

Something between "6 degrees of separation", Advogato's trust metrics, and PGP's web of trust.

I know and trust these 3 people and you know and trust me so you can trust these three people.

And then tying it to a personal networking app. "Find me the top 10 people who specialize in web services strategy."

One key issue is trying to find or create an activity that is equivalent to the web page link to base the metric on.

Whew! That was close. My wife forgot our wedding anniversary as well... 

So Google have a SOAP API. This was just the excuse I needed to start playing with SOAP in PHP. And thus the game began.

First I had to choose a SOAP implementation. It turns out that php-PEAR has one that seems to be based on the well respected SOAPX4 I also wanted to start experimenting with some other libraries in PEAR and the code has a sort of quasi-stamp of approval from PHP as it's now in the main distributions. But for some reason PEAR wasn't installed on my hosting machine probably because I did it.

So the next stage is to update PHP from 1.0 to 1.2 and thereby hangs a tale. Now I host with Interland with their cheapest hosting package that gives me more or less full control. I get a virtual root in a sandbox but can access httpd.conf and such like. Interland told me that I couldn't update php because I needed full su root access. Hah! What do they know? Download php, untar it, work out what config parameters I need from phpinfo(), run ./configure etc, run make, run make install and let it fail. Sure enough, there is libphp4.so in the libs directory. Copy it to my own lib directory and then adjust httpd.conf so that the LoadModule php4_module line points at my copy instead of libexec. Restart apache and Bingo! php 4.12.

So now the next stage is to work out what happened to PEAR. It ought to go into /usr/libs but I don't have write access there. But I can see all the PEAR libraries in the php source tree. If I put it in usr/local/dah/dah/dah/libs then maybe I can get php to find it. Sure enough the php.ini file needs an entry include_path = ".:/usr/local/dah/dah/dah/lib/php/pear" Restart apache, run a short web page test for the pear DB library and it works. Bingo 2!

Now of course, so far I've glossed over several hours of trial and error and inspired guesswork, but the plan is coming together.

So now for SOAP. PEAR SOAP isn't in the php distribution but a quick Google search does turn up some minimal documentation and evidence of it being in the PEAR CVS. There's supposed to be a PEAR package manager that makes getting a new package easy. This is the point where you hit a web page on CVS PEAR install that says "This page not written yet". So finally I find the installed pear.in script that has to be moved and renamed pear and the instruction that says you need php to run it. Oh well, back to step 2 while I build a stand alone copy of php. Ok so I can see the executable. It's got execute rights. I type php, hit enter and get command not found. huh? It's right there. It takes me several minutes to realize that in Unix that should be ./php (stop laughing at the back) Makes complete sense. I have to tell it to run this php right here, not any old php it might find in the path.

So now php works, I can change the #! line at the top of the pear script to my copy, run ./pear So. list-available looks like a good option. Bang! xmlrpc support not loaded, error, error, error. ok, so we'll come back to that.

Then I remembered a note on a page about accessing Google API from php. "To use this code you will need both PEAR and the PEAR SOAP package installed somewhere on your php include path. You can get the SOAP package from CVS:" Have we got CVS? Yes. Type in the suggested lines. Bang! Some stupid CVS error that I can't be bothered to debug. OK. type the same lines into WinCVS locally. It all works, there's SOAP/, ftp it into the server's PEAR tree, fire up the sample php file, BINGO! Google search results! Try another search, Bang! No results. Ah-Hah! So when the note in the top of the example file said some returns don't work due to a bug in PEAR/SOAP parser it meant it.

So the next day, I have another look and the file now says "The PEAR SOAP package bug which caused some search terms to fail has now been fixed." So WinCVS, update, ftp, try again and Bingo!

So now I've got Google search results coming out of php code. Amazing.

But what was all that stuff about xmlrpc, package managers and such like. Well it appears that php now includes support for xmlrpc using Dan Libby's epi library. And because of that the PEAR guys assume it's there and use it in the package manager. And the php install docs say just use --xmlrpc(=DIR) as a config parameter. Well of course, I'd tidied up all the source, so download and untar the php source again. Add the parameter, check ./configure. Except that some of the xmlrpc responses look incomplete. Run make anyway, Bang! iconv.h missing. What? What happened then? Maybe I'm supposed to install xmlrpc-epi.c first. Download that, untar, configure, make, Bang! The Makefile borks with some impenetrable message. So it's off to the sourceforge pages, where I find a whole lot of equally impenetrable messages about how maybe FreeBSD is odd. Or maybe this or maybe that. But nothing that says "Do it like this and it'll work"

Now core PHP is really good. The docs are great, the code works, the install works. But step off the beaten track and we're back into Nerdland where it's assumed that you "Have a Clue", can debug other people's makefiles and can just know what to do by some weird telepathic osmosis.

Postscript: What I really wanted to do is put some cool Googley SOAP code into Theecademy.com But I have even less control there and they're running php 4.0.6 with no hope of getting an upgrade and no PEAR. But I copied all the useful files across, used a line in .htaccess to set the include_path. The test code said "requires PHP 4.1 or higher". Oh really? Comment out that check and it says array_key_exists() not found. And the php manual says "The name of this function is key_exists() in PHP version 4.0.6" So global search and replace through all of PEAR/SOAP and Bingo! Googley search results.

Netmaster 10baseT is in the house It's the BOFH Rap!

Yah gotta love this. Automatic blog entry creation with .:Autolog:.. For those days when you feel uninspired...

A dystopian vision of Life On the Net in 2004

Have you noticed how people have started referring to Yahoo! as Y!. Should this be pronounced Why Shriek? or Why Bang?

And what about the characters often found at the top of perl and shell scripts #! Is that Hash Bang ?

Microsoft has announced pricing for their MapPoint.NET service; yikes. And the uptime is only three nines. Hopefully MapQuest or Vicinity will come out with a service that supports the same API so we can get some price competition going. [thanks, Hack the Planet] Is this the first example of chargeable public web services? Platform Access Fee = $15,000.00 USD, Per User License = $299.00 USD, Per Transaction = $0.01 USD with a 45 day free trial. Presumably MS will release a toolkit to help others copy this approach. As HTP says, it will be interesting to see if equivalent services from other providers can provide realistic competition and drive the price down.

Demo: Reconfigurable Robots PARC's Mark Yim shows off his robots, which reassemble themsleves to slink like snakes, roll like wheels or scamper like lizards. [thanks, Technology Review - Computers and Electronics] Yummy. I love this stuff.

Tim O'Reilly reports back from the Alpha Geeks on the front lines.
http://www.oreillynet.com/pub/a/network/2002/04/09/future.html
"The future is here. It's just not evenly distributed yet"

1. Wireless. Don't be Wired, be Wireless
2. Next Generation Search Engines. The one after Google.
3. Weblogs. Journalism 3.0. The readers fight back.
4. Instant Messaging. With APIs for programmers
5. File Sharing. Napster died but free music lives on.
6. Grid Computing. That's Seti, Protein folding and code cracking. What's
next.
7. Web Spidering. the Internet is huge and it's all mine.

All this seems awfully familiar, Tim. I thought you said this was the future?

Geographic guesswork about where you are physically, based on hints in your tcp/ip from Threering.net Click here now

Limited Pie. A Home for Scarce Thought on the Net : A Modest Post-Napster Proposal Rather wonderful proposal in the spirit of Swift to deal with music copyright, by producing, storing and copywriting every possible 4 minute song in MP3 format with distributed computing and storage. An MP3 is just a very long binary number. Cycle through every possible binary number of this length and you have all possible songs. Unfortunately the math is a little out, but it's still within the bounds of possibility.

A photocopier for CDs   Australian convenience-stores install coin-operated CD duplicators. The machines are able to operate under the same legislation as public photocopiers, where the burden of responsibility for copyright breaches lies with the user and not the owner of the equipment.Link [thanks, bOing bOing] Unbelievable! But it makes perfect sense, why not?