This talk is worth a look. Forgive the title (which is a misnomer) and the way it frames REST; equating it to feeds designed to be consumed by polling clients - Newtonian physics to PubSub's quanta (poorly formed analogy). REST and RPC simply are suited to other types of services (I fail to see how RPC over XMPP is useful unless the time to process a request is long and callbacks are required). The talk goes on to use concrete examples that illustrate how hijacking Jabber servers and XMPP for generic push messaging using a pubsub architecture is far more efficient for lots of web services outside of IM that are currently pull-based. They even manage to fudge oAuth in for protected resources. It's the kind of pragmatism that smacks of real life problems solved (I salute).
I'd be very surprised if Last.fm's 'now playing' notifications didn't switch over to pubsub very soon.
Glad to have been a part of this in some way (I handle all the API's). Now all we need is for Apple to approve the app for their store.
Update: It's been approved now so you can download it for free from the store. Toby has the full scoop.
It's been a strange week for me & the GOOG. First, Rob pointed this out in the new Adwords API T&C:
3. Inspection for Compliance.
1. User-Interface Inspection. You agree that Google may inspect your AdWords API Client user interfaces up to 3 times per calendar year. Any such inspection must be during normal business hours. You must allow Google to visit your place of business, or inspect your AdWords API Client in some other manner agreed between you and Google, within 7 days after notice from Google that Google desires to inspect your AdWords API Client interfaces...
2. Systems Inspection. In addition to Google's rights under Section IV(3)(a), at Google's expense (except as set forth below) Google may appoint (subject to the below) a Third Party inspector (the "Inspector") for a systems inspection, only as set forth in this section, of your AdWords API Use...
Que? For the pleasure of talking to you we get a day trip from an 'inspector'? Whilst i like catching up with GOOG folk to talk falling stock and vint cerf's breakfast habits, i think this is over-stepping the mark a little. Both parties using an API can pretty clearly discern who's playing nice and who isn't without visiting each other's premises and inspecting products.
This came with the news that the Adwords API has a new 'feature'. Usage is not free anymore! The old quota caps system has been replaced with a pay-as-you-go type deal. Coupled with the fact that google doesn't provide test accounts, this could mean that if you're developing an Adwords client for your app you'll be spending every step of the way. Still got to wait on this, but it sounds both more flexible and more costly.
Finally, Google Calendar came along, with great desktop UI touches like cell dragging to define event duration:
And google map integration and all sorts of other treats.
And suddenly everything is ok again with me & the GOOG and i forgive them and they can send inspectors to my house to question my family about my API usage and i'll even make them continental breakfast. With fresh croissants. On a Sunday morning.
Gigr.net is a community driven gigs portal built on Ruby on Rails. It already talks to audioscrobbler & itunes (to pick up your listening habits) and exports iCal calendars / RSS feeds with shows involving the bands you're currently listening to. It's heading in the right direction by learning to talk early on. What i mean is that this kind of service gains value by playing well with others and that's precisely what Gigr has set out to do. Solid import/export options already.
Anyone can upload information about shows/artists/venues. Username/email is all that's required to sign up for free. Do it. It's just getting off the ground but there's already a ton of shows in there.
Note: If you're a Rails developer then get talking to Ernest about access to the SVN repository. This is just the kind of service that could wind up embedded in something like the last.fm service.
Twelve weeks with geeks is on google video - trailer here, feature-length for purchase here.
I particularly like the google vid query syntax,
geeks is:forsale
Will give you the feaure-length version. It's more intuitive (natural language) than some of the queries you have to come up with on google search proper,
"parent directory " MP3 -xxx -html -htm -php -shtml -opendivx -md5 -md5sums [artist] [title]
On the other hand, google video frames its credit card form, forcing you to think twice about the SSL nature of the transaction.
Boo google.
In case you'd missed it - Google Earth is now on OS X. I managed to locate my grandparent's place in New Delhi. That's something.
Note: Google video purchases are still US only. Complete bummer.
I've been using this PHP Flickr Api class on Kontent for about a year. I just hacked it up to meet my needs, so i've only implemented a few of the calls. Works a treat. Thought it might be useful to someone.
You get:
- getPhoto
- getPhotoPool
- getPublicGroups
- getPhotoSets
- getSet
The Flickr_API object works on any PHP version > 4.0.5 as far as i know. Its only dependency is XPath, which is just one class. Place the XPath file in the same directory as the API or tweak the include manually.
You can switch user at any moment and find user id's by email address - this means that with the implementation of flickr.contacts.getList you could use the object to map Flickr networks.
Uses the Flickr REST interface. Simple as pie to extend.
Quick usage example.
create new object and fetch sets for default Flickr user (set this in object),
$api = new Flickr_API();
$set = $api->getPhotoSets();
Output user's sets to HTML,
foreach ($set as $s)
{
// get primary photo in this set to use as thumbnail
$photo = $api->getPhoto($s['primary']);
// output thumbnail with title, number of photos in set and description.
echo '<div class="media_img">
<a href="visual.php?photoset_id='.$s['id'].'" class="box">
<img title="'.$photo['title'].'" src="'.$api->getImageURL($photo,'t').'" border="0" width="100" />
</a>
</div>
<div class="linkbox_m pictures">
<a href="visual.php?photoset_id='.$s['id'].'" class="box">'.
$s['title'].' ('.$s['photos'].')
<br>'.$s['description'].'
</a>
</div>';
}
Click here to download flickr_api.tgz
Domain Name Registration - a murky business at best.
I purchased a domain name / hosting bundle from an American web host with a good track record today.
Or so i thought.
It appears that in the intervening period between my placing the order and the host processing the order, an employee of Yahoo! had purchased the domain name I wanted. Literally in the 2-3 hour window, one Russell Beattie from California had gone and had exactly the same idea as me. At least that's what WHOIS is telling me.
Now this is interesting. It's obviously no coincidence.
The domain name indirectly refers to a piece of technology Yahoo! recently bought. I chose this name for an application i'm working on for my dissertation here at Imperial College.
I searched for it's availability on two occassions today (at two webhosts). These query public domain sources to establish domain name availability. It would appear that somewhere along the line, someone is filtering domain name queries and passing them on to interested third parties. Members of the IT industry appear to be screening domain registration requests for potential ideas/threats to their products. This is the impression i get. I may be mistaken but it's certainly a sensible thought, given what's just happened. I'm kind of flattered someone at Yahoo! thought my domain name idea to be potentially hazardous or of interest to their business.
Ah, the power of words.
A group blogging project in the form of a web services mashup built on Movable Type. Includes shared events calendar, flickr photo galleries and delicious links. Dealt with digital culture in London, UK. Ran from 2001-2005.
