web 2.0

After an hour or two of sleuthing I’ve discovered that jQuery 1.2.6 does not set the Content-Type header for HTTP GETs even if you explicitly use the contentType parameter. My understanding of the jQuery rationale is that GETs don’t contain data and therefore a Content-Type header is not required. Unfortunately, Microsoft reckons that GETs returning JSON provide a security risk and that a Content-Type header must be specified. Scott Guthrie explains it here http://weblogs.asp.net/scottgu/archive/2007/04/04/json-hijacking-and-how-asp-net-ajax-1-0-mitigates-these-attacks.aspx.  

After reading documentation from both camps I can fully understand their opposing views.  Ultimately it is yet another indicator that the responsibility of user protection lies in the browser is blatantly wrong!  If the browser raised a message asking the user if they are ok with a cross domain request and acted according to the response it would render both jQuery’s and Microsoft’s approaches obsolete.

So now I am caught between a rock and a hard place.  I love jQuery and I love Microsoft ASP.NET webservices and I am going to use both in my current projects.  But, if I can not explicitly set the Content-Type header for an .ajax() GET then I have just one choice and that is to use POSTs instead.  Unfortunately this contradicts the notion of using the correct HTTP verbs and removes the possibility of a RESTful API. 

It’s always about compromise.

 Y Combinator is a VC-slash-Incubator organization that seems to be producing some interesting companies (with a definite leaning toward Flash based technologies). They recently held a demo day to showcase some of their apps. The following ones caught my attention for the reasons described.


I have been using anywhere.fm for a couple of weeks now and really like it. Although I have a bit of an aversion to Flash apps hosted in web browsers this actually seems like a great implementation. That said, it wouldn’t be that hard to pull off as an Ajax app. My company’s next product code-named m*******t will do some similar things and with a much better interface 🙂 For now, you can create an account at http://www.anywhere.fm, upload your music collection, the stream it from any other Flash enabled browser. From a SoNet perspective you can stream, but not download, your friends music collection too.


Another product out of the Y Combinator world is Versionate. While it is yet-another-wiki-as-a-hosted-service it is dead easy to setup and use. I think one of its biggest attractions to me is that is has so few features. If you need a feature-rich and robust wiki solution then look elsewhere. However, if you are looking for something easy to setup that loads quickly and allows you to capture a thought mid-stream then this is well worth the consideration. We have a very informal (aka non-existent) documentation process where I work. I am finding versionate invaluable in capturing, storing and organizing critical information.


I just came across fauxto this evening so I have not had any opportunity to use it yet. According to the claims it offers a lot of the functionality of Adobe’s Photoshop in a web delivered Flash app. Since my forte is in server-side development I can not justify the license for Photoshop. However I do find myself having to do basic image manipulation from time-to–time and it is almost always for low/non paying charity gigs where I can not leverage the kick-ass front-end skills of some of my designer friends. I’m looking forward to trying out fauxto in the coming days.

If you are interested in learning more about Y Combinator then check out the link. If you think you have a great idea that is worthy of their financing then take a look at www.ycombinator.com/w2008.html where they talk about their application process and deadline for next round of financing and assistance.

Y Combinator Demo Day: The Summer Startups

This useful list of 20 online CSS tools was posted on CSS Juice a couple of days ago.

CSS Juice – Design, Tutorial, Showcase and more » 20 Popular CSS Online Tools and Generators

And more importantly (for adbeast possibly) it will support QuickTime.  Depending upon how they implement the interface and the uptake on browser plugins this could have a major impact on the internet video space. 

Real Networks announced today that it will be launching a new version of its dying video player this June. Unlike previous versions of the player, the new version will support file types other than just Real files, including Windows Media, Flash, and QuickTime. The new version of the player will also allow users to download video streams onto their computers. This means that users will be able to save their own copies of videos from sites like YouTube, MySpace, Soapbox, Revver, and more with a single click instead of relying on more convoluted methods.

New RealPlayer to rip YouTube video streams

Originally uploaded by adactio.

This came from the recent Web 2.0 conference. Unfortunately the prototype library is missing from list of panelists. However, if it was there it would probably sit somewhere between YUI and Dojo and between websites and applications (in my opinion).

Everyone knows that saying “you get what you pay for”. So when we start using any one of the hundreds of web based APIs for free what sort of assumptions can we make about it? For instance:

  • How long will it be around?
  • If it changes how will I be notified so I can change and test the code in my application?
  • What if my application receives so many hits that it overwhelms the server I am mashing up to?
  • Can I realistically use this API (which will solve all my problems and cost me nothing) in my application?

While I have played with a few of the available APIs I find it very difficult to consider using them in any of my applications. And this includes applications I am architecting for my employer as well as some of my smaller, non-profit community applications I am building in my spare time.

My concern is that someone offering web services, data and an API at no cost has no real obligation to me as the consumer of that information. While it is in the best interest of some of the larger players to maintain their API (think Amazon, eBay, etc) the smaller organizations could decide to take down their provision at any time if they feel they are not getting anything back from it or perhaps their limited bandwidth is being exceeded. At the minimum this could result in a severe disruption in service for my users. For that matter, how can I make any statement of service or availability to my users if I am depending upon external services themselves not providing this statement.

Perhaps we need to see an emergence of a standard SLA that gets published much the same way a privacy statement is. If the provider of the API communicates their intended service level then consumers of that API can make a more informed decision. Unfortunately, I think the type of information that would need to be disclosed would often be considered confidential and proprietary.

I have been using xml and xslt for over a decade now and find it a great format for exchanging data between systems.  I used to use it for sending data between a web server and browser in my “corporate” days.  All of my work back then was for various fortune 500’s where the browser was dictated to be IE so transforming xml using the msxml libraries was a cinch.  Fast forward to now where I’m designing Ajaxified cross platform web applications and suddenly xml can’t be used.  The cross-domain issues and non-standard transformation support make xml consumption a nightmare at best.

This is becoming a bigger issue for me (and many others I suspect) as I try to dynamically load and consume RSS feeds cross-domain.  So now I am investigating a simple solution – JSON.  JSON data can be easily obtained from other domains and it can be queried in a similar fashion to xpath by simply walking the object/property structure. 

Today almost all RSS syndicators are publishing in the traditional XML format so it is necessary to parse RSS to JSON somehow.  Hopefully this will change and a complimentary javascript format will emerge.  In the mean time I am going to find/build some tools that will perform this transfer on the fly.

My first such tool uses Yahoo Pipes to grab the headlines from the Ajaxian RSS feed.  I have published a stupidly simple Pipe that can be found at http://pipes.yahoo.com/pipes/pipe.info?_id=_osFeI7W2xGPFy3cqGIyXQ.  It takes one parameter; the URI of a feed and simply retrieves and returns the contents of the feed.  The cool thing is Pipes can be forced to output in JSON format rather than XML by simply setting the _render querystring variable to “json”.

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml” >
<title>Untitled Page</title>

<script language=”javascript” type=”text/javascript”>
var pipeCallback;
var data;
function pipeCallback(d) {
data = d;
var arts = d.value.items;
for (var i=0; i<arts.length; i++)
var a = document.createElement(“a”);
a.setAttribute(“href”, arts[i].link);
a.innerHTML = “<h1>” + arts[i].title + “</h1>”
var dv = document.createElement(“div”);
dv.innerHTML = arts[i].description;
<script type=”text/javascript”src=”http://pipes.yahoo.com/pipes/pipe.run?urlinput1=http%3A%2F%2Fwww.ajaxian.com%2Findex.xml&_id=_osFeI7W2xGPFy3cqGIyXQ&_render=json&_callback=pipeCallback”></script>

Next I am going to build an XSLT to transform an RSS file to its JSON equivalent.

Next Page »