Cross-Domain Portlets with Start.com Gadgets/Widgets/Startlets

Scott Isaacs on a new Start.com feature (quoted on Ajaxian):

DHTML-based Gadgets: Start.com consumes DHTML-based components called Gadgets. These Gadgets can be created by any developer, hosted on any site, and consumed into the Start.com experience. The model is completely distributed. You can develop components derived from other components on the web.

Remote portlets take the Ajax portals to another level. In fact, the whole concept is one of the biggest developments in the history of the web. A9 pre-empted it with their “Open Search” capability, which allows developers to hook into the A9 interface with live search results. Now MS is going a step further, with Konfabulator-style interaction directly on the web. It’s likely Yahoo has similar plans, given that it’s now the owner of Konfabulator. What Google does is anyone’s guess. Strategically, MS has a big edge here because of its experience working with Developers, Developers, Developers! (YES!)

The idea combines [Cross-Domain Mediator](http://ajaxpatterns.org/Cross-Domain Mediator) with Portlet. Those patterns have subsumed a now-deleted pattern that previous covered this kind of thing:

Cross-Domain Portlet: Introduce Interactive Portlets to facilitate a conversation between the user and a third-party, e.g. for services or “advertising as conversation” (http://radar.oreilly.com/archives/2005/05/remaking_advert.html)

Ajax makes it possible because there’s no page refresh. Conceptually, each portlet is autonomous and capable of conducting a conversation with another domain in parallel with other portlets. When a result comes back to one portal, the other portlets are unaffected. (You can obviously yoke portals together if you want to.) In practice, there are a couple of finer implementation points:

  • You can’t make an XMLHttpRequest Call to an external domain. Hence, the portal server must mediate.
  • Conducting parallel conversations, you’ll need some form of Call Tracking. Hopefully, you’re using a library that abstracts those details from you.

Now that a happening, here are a few things I’d like to see:

  • An open standard for conducting cross-domain conversations, one that protects the end-user and the portal host, but provides sufficient functionality to the
  • Useful ads (the advertising as conversation) concept. There’s definitely a business model here for opt-in advertising. That is, users would be willing to add advertising portlets that offer genuinely useful information. e.g. a travel portlet that lets you check flight availability.
  • RSS aggregator integration The nature of a portal can change, right? So RSS aggregators should be able to include remote portlets.
  • End-user-created portlets. Make it easy for end-users to construct their own gadgets. This idea is inspired by Charlene Li’s comments on Konfabulator: “The problem is I already know what the ultimate widget would be me … There’s only one small problem — I don’t know JavaScript! So I am at the mercy of app developers …”

0 thoughts on Cross-Domain Portlets with Start.com Gadgets/Widgets/Startlets

  1. Pingback: Software As She’s Developed - Blummy: The Mother of All Bookmarklets

  2. Pingback: openlogic.biz » Software As She’s Developed - Cross-Domain Portlets with Start.com Gadgets/Widgets/Startlets

  3. Understanding this article is dated, how would you approach this today.? My goal is to create a “portlet” that can get its content for another web application’s partial view (that I create ) and inject that content on my page, maintaining its functionality and using my styles.

Leave a Reply