Topic Archive: Mashups

SMash - Something Useful from the OpenAjax Alliance?

Dietrich Kappe, Friday, February 8, 2008 @ 3:06 pm

In the announcement that the OpenAjax Alliance had released OpenAjax Hub 1.0, and would start to work toward 1.1, there was one thing that caught my interest: the news that 1.1 would support secure mashups. Given that proxies and JSONP are both pretty open to abuse by unscrupulous service providers, this was certainly welcome news? So, what exactly does this secure mashup support look like?

The nascent SVN repository at Sourceforge wasn't much help -- mostly just a placeholder for future work. A little digging reveals that the OpenAjax technology will be based on a technique known as 'SMash', developed at IBM for performing secure mashups. I was able to locate a copy of a research paper on SMash (not sure if this is meant to be public, so grab a copy).

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

agile ajax

Top 15 music APIs to power your next mashup

Brian Dillard, Wednesday, February 6, 2008 @ 1:48 pm

Music and the web have a long history, from Napster through the iTunes Store to the MP3 blogs of today. For Web 2.0 hackers, however, the availability of public APIs proves pretty hit or miss. Cool mash-ups do exist - for instance, TuneGlue MusicMap, which provides nice visualization to data from Last.fm and Amazon. But lots of the big music databases don't offer public web services. Indie download site eMusic used to, but stopped, while big commercial entities such as Muze and the All Music Guide keep their data stores proprietary and pricey. (Full disclosure: I frequently write freelance music reviews for AMG's sister site, the All Movie Guide.)

If you do a little hunting, however, you'll discover lots of web services that deliver powerful music content. Licensing terms vary, but the following 15 links should provide enough content to power tons of cross-pollination:

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

Tibco GI/Craigs List Bashup

Dietrich Kappe, Thursday, October 4, 2007 @ 11:44 am

Over at Ajaxian you can read about a pretty cool remix of Craig's List, somewhat similar to what I've been working on with GWT. I've termed this a "bashup," rather than a "mashup," because it kind of mashes things up against one or more of the participants wills. Now, whereas my solution will be injected into the site's page via a bookmarklet, this mashup proxies Craig's List through it's local server. I'm pretty sure that violates Craig's List's TOU (see article 12, ACCESS TO THE SERVICE).

Technorati Tags: ajax, tibco gi, craig's list, mashups

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

.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

Mashups versus Facebook

Dietrich Kappe, Thursday, July 5, 2007 @ 6:02 am

I've been playing around with the Facebook API over the last few weeks. There's only a very limited Ajax capability in the API -- they call it "Mock Ajax" -- that allows you to sub some very restricted HTML into the innerHTML of DOM elements. No Javascript. You'll have to use inline CSS if you want to achieve a cool user experience.

While it is possible to display Facebook content in your own apps, it is pretty restricted (you'll have to read at least three legal docs to figure all that out). Not much leverage for mashups here. In a sense this is the mirror opposite of a mashup. Instead of mashing together services provided by third party, you develop a service that is mashed into the Facebook platform.

Part of the promise of Ajax was that you could mash together third party services quickly and comparatively easily. While widgets and services have made their mark (Yahoo, Flickr, Google Maps to name just a few), there is also a trend toward restricting their use. See the discontinuation of the Google SOAP Search API and the heavy restrictions on the new Google Ajax Search API. Right now my money is on the Facebook model winning out over the Mashup model.

BTW, in exploring the Facebook API, I experienced a flashback to the late 90's and the whole portal fad. The API's and patterns reminded me more than a little bit of Plumtree and Epicentric (great portal platform before it was absorbed into the craptastic Vignette). What's old is new again, just like bell bottoms and mood rings. Just don't call facebook a portal.

Technorati Tags: ajax, facebook, portal, mashup

• Digg
• Reddit
• del.icio.us

Comments (2)

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