Topic Archive: Web Services

.Mac improvements: That’s it?

Brian Dillard, Friday, August 17, 2007 @ 5:30 am

Amidst all the hardware news at Apple's Mac-focused media event last week, it was easy to overlook the announcement of some tweaks to the widely reviled .Mac web-services suite. Easy to overlook not because the announcement got no play, but because the improvements were so underwhelming. Even with 10 times the online storage space (10 gigs, up from 1 gig) and a slick new Ajax-backed photo service, the upgraded .Mac suite still costs $100 a year. Meanwhile, most of its individual features continue to lag behind the functionality and performance of free services from a host of other providers.

Commentators here, there and everywhere have predicted - and in many cases advocated - the death of .Mac for a long time now. I wonder if Mac newbies' continuing propensity to pony up for the service has something to do with Google's inability to parse the period in ".Mac" and return some relevant search results for such phrases as ".Mac user reviews." [Here's a hint: search for "dot-mac sucks" instead.] There's no shortage of users who find the service disappointing, and the latest tweaks aren't likely to change that.

Based on the demo I've seen of the new .Mac Web Gallery, I can see why an iPhoto junkie might be persuaded to dump Flickr and give it a whirl. But why settle for syncing Safari bookmarks when you can use a social bookmarking service or a bookmark-syncing plug-in for your browser of choice? Why settle for viewing your Address Book entries from a primitive web interface when a service like Plaxo lets you edit them online, too? Why merely view iCal entries online when you can actually edit your Google or Yahoo calendar from any browser? Why use .Mac's painfully slow, frequently buggy online backup service when you can switch to Amazon's S3? Why use the old-school .Mac webmail client when all the major free webmail vendors offer snappy Ajax interfaces? Why host your personal site with iWeb when so many other free or low-cost solutions offer more flexibility and power?

No webapp is perfect, and no single provider offers the breadth of .Mac in a single suite. But cheap or free a la carte services from best-of-breed providers work better for all but the most dedicated (or lazy) Mac users.

Leander Kahney over at Wired stayed up late the night before Apple's presentation to say a prayer that Jobs & Co. would radically overhaul the service. But the best that can be said about the "new" .Mac is that its developers finally seem to be dimly aware that there's this whole Web 2.0 thing happening out there. The future promises some upcoming, though as-yet-undefined, .Mac webmail improvements that could help modernize the service. But the suite's most compelling features are the ones that link one Mac to another, such as Leopard's forthcoming Back to My Mac application. True Apple fanboys may get a lot from such utilities, but they're useless for people in the real world - the ones who log onto Windows boxes at work every day and still want access to the data from their personal MacBook Pros.

My real problem with .Mac isn't that its webapps are sub-par. It's that Apple's overall strategy in the PC marketplace is still so focused on a single, unified desktop experience geared toward the mythical "average user." (Thanks, Walt Mossberg, for making that the most overused phrase in technology writing.) It's such a Microsoftian strategy: continually cramming all the the things a typical customer might need into a suite of pretty-good apps and services whose only real advantage is their supposed integration.

Given that Safari is being positioned as the platform for iPhone software development, it seems likely that core pieces of the OS X desktop experience will eventually get better browser-based simulations. But as a Mac user, I want the data on my machine to play well with third-party webapps, too, in my user-agent of choice. The whole advantage of the web desktop model is that all of my data lives in the cloud and, thanks to public APIs, I can interact with it through a broad range of providers. I can use the out-of-the-box UI or create my own. I can aggregate Remember the Milk into my gCal with a widget instead of waiting for Google to come up with a first-rate to-do list manager. I'm not locked into a single piece of hardware, operating system or software vendor. But locking me into a monolithic suite seems to be the whole point of Apple's desktop strategy, .Mac included.

Right now, all .Mac does is sync data between Macs and allow me to access a subset of that data, in read-only mode, through the browser. That's simply not good enough, and it hasn't been for a couple of years now. Apple should be integrating each of its elegant, easy-to-use but fairly vanilla desktop apps into a web-services architecture. That way, I can use my Mac as an oasis of no-fuss desktop computing at home, but still have the power and the flexibility to do what I need to do from any other machine or physical location.

I get why Apple's user interfaces are geared toward somebody with my grandmother's level of technical proficiency. But why not set up .Mac so that third parties can create more powerful and varied UIs on top of the underlying services? That might actually be worth $100 a year. In the meantime, .Mac and the Macintosh platform are positioned as one-size-fits-all, all-or-nothing propositions. And there's nothing new about that, media event or no.

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

>API Keys for Ajax Services

Dietrich Kappe, Monday, August 6, 2007 @ 5:35 am

I'm sure not everyone is developing Ajax-based front end sites and applications. There must be someone who is developing XML, JSON and JSONP web services, right? So, if you are going to offer it as a commercial service, and even if you aren't, you still want to be able to control and measure access to it. Something like those Google and Yahoo service API keys, right? I'm sure we've all worked with MD5 and SHA-1 enough to have some ideas about how that would be done, but it helps to have an example to follow.

Well, check out this article over at java.net: Creating and Using API Keys with Java Based Ajax Services. It demonstrates the client and server side pieces to using an API key. Lots of code, and shows how to generate the key from the client web site address and a secret service token. (Note: the example relies on the now outmoded MD5 to generate the token, but that could easily be switched to SHA-1 or some other one-way hash.)

Technorati Tags: ajax, json, jsonp, api key

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

Web Serice and Mashup Pros and Cons and the First Google Clone

Dietrich Kappe, Thursday, September 28, 2006 @ 10:46 pm

Over at Web Directions South, a good collection of pros and cons regarding web services and mashups from Kevin Yanks and Cameron Adams. Some choice things from the list

• Having an API allows external programmers to access your data in a smart way. Page scraping is so Web 1.0
• Programmableweb.com acts as an encyclopaedia of what APIs are available and what people are doing with them.
• The amount of data mining capable through APIs is potentially frightening; especially if you're the paranoid type.
• It's not all about maps - TagTV, Viral Video Chart, BlueOrganizer, Salesforce Adwords.
• Cross Domain AJAX is a security risk that has come along for the ride. You can load images, CSS and JavaScript from other domains, but cannot load HTML or XML. JSON-P gets around this by disguising the new data as JavaScript. The potential problem here is that your data provider could very easily inject malicious script if they wanted to. JSON-P only supports GET requests and fails silently if you get the API URL wrong.

One thing I was not aware of was that a company down under -- ZoomIn -- is providing a google maps-like interface. I guess google maps for New Zealand and Australia leave something to be desired, leaving an opening to an upstart that looks a lot like google maps. You can include maps on your site, and the Javascript API looks just like the Google one.

What does this all mean? It means that in Australia and New Zealand if you don't like google or it's terms of service, you can use an equivalent service with a minimal change. Is this the future of online services, or are we about to see a raft of API lawsuits? Hard to say.

 
  Technorati : google clone, mashups, soa

• Digg
• Reddit
• del.icio.us

Comments (1)

agile ajax