Let’s start this post with what BBAuth is and what it can be used for. It was designed to allow third-party applications to interact with user-specific data with the users’ consent. On top of doing the obvious, it supports Single Sign-On out of the box.

That means you can build applications that instead of creating your own sign-up flow, which requires users to pick yet another username and password, you can let them sign in with their existing Yahoo! account. The best thing about it is that it’s safe, the YahooId does not get shared with the applications. Your application needs to redirect the user to the Yahoo! BBAuth login and after the user successfully logs in, your app will receive an encrypted and unique userid for each user that logs in. This sample application makes use of SSO.

Good or bad? That is up-to-you do decide. My opinion is that this can make navigating the web so much easier for users, and I am one of them! I don’t want to have to remember ‘x’ usernames and ‘y ‘passwords and keep adding to the list everyday. There are also other ways of dealing with that problem, but here is a solution that is really straightforward. Feel free to leave a comment and let me know what you think! I want to add that this is not driven by a huge initiative to get everyone on Yahoo!, but an attempt to put out another tool that developers can decide to adopt if they like it.

But that’s not all! Yahoo! Photos opened up an API that takes advantage of BBAuth as well. I wrote a sample application that is using it, which allows user to view and update titles and descriptions for photos stored on Yahoo!. The ajaxy parts are using the YUI libraries. On top of all that, we are doing a private beta for developers who attend our public Hackday! The new Yahoo! Mail is opening up their backend!! Appid sign-up will be limited for now but stay tuned for future updates.

For me, this has been quite a ride from the first time we talked about making BBAuth happen until today, the day we finally launched. In a big company like Yahoo!, you need to get input / approval from quite some folks if you want to do something out of the box and open up the company. All that makes sense and is justifiable but sometimes I wish it would have been faster. On the other side, I learned a lot about the company I work for, how big companies work in general, egos, friends and allies and most importantly how you get stuff done that is obviously not on everyone’s “need this today” list.

Like most platform projects that have to support a lot of different use-cases, the list of people that have made this happen is very long and I don’t even want to try to list them all. Instead I want to send a big “general” thank you out to all the thinkers and do-ers, the try-to-stop-it-ers and the must-have-today-ers! Thanks to all of you for making it what it is today!

Further reading: On the Developer Network page we have the official announcement. Jeremy posted something on his blog as well. Without his help to clear last minute “congestions” I am not sure if would have gone out today :)

Besides the entertainment and classes we will have networking, coding, camping, presentations, wifi, food (not free – sorry, we spent the $ somewhere else), parking and and and. It will be a lot of fun! If you didn’t sign up already, this is your last call! You can do this on Upcoming.org.

Sidenote: The timer on the hackday page gets powered by the RESTful getTime web service that I wrote for fun. How much more basic then getTime can a web service get? That’s not the point :) The nice thing about it is that it supports JSON and serialized PHP on top of the XML output.

Big parts about Web2.0 are openness, web services (which support #1), a social network and, and, and!

Openness…! I was using del.icio.us and when MyWeb launched I tried that out for a while. A couple of days back I decided to export the MyWeb links to sync the two accounts.

The problem: The MyWeb web interface only gives you a list of bookmarks similar what Netscape 4.71 did.

The good news: MyWeb has an API that let’s you get to the links, tags, description…! One limitation is that the API does not support authentication and therefore only returns public bookmarks. Del.icio.us on the other hand supports authentication which enables application to add links on behalf of a user. That is all that’s needed to solve the problem above.

Why Python?: I didn’t program in that language before and inspired by Simon’s Python Developer Center I had to give it a shot.

Check out the Source Code – Python MyWeb to del.icio.us Exporter!

I put together a little page that uses the two new calls with the JSON output to display trip details.

Today Yahoo! added a new output option for part of their Web services called JSON. This makes it possible to make the JavaScript WS request without using the XMLHTTPRequest object. It is a great way to pull data from another domain because you can dump your proxy and all the data will not route through your server anymore. I will talk about the pros and cons of both these approaches later, but first I want to give an overview of what JSON is, how it works and show some sample code.

What is JSON?

On Doug Crockford’s page it reads like that: "JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate." And that’s how it look like:

{"ResultSet":{"Result":[{"precision":"city","Latitude":"34.05217","Longitude":"-118.243469","Address":"","City":"LOS ANGELES","State":"CA","Zip":"","Country":"US"}]}}}

The string above is returned by Y! Geocoder for the query “LA”. JSON is a serialized JavaScript object, which JavaScript can turn back into an object. For Yahoo! WS the structure of the JSON string is similar to the XML result but the difference between and attribute and element can’t be made. The following is a comparison of the XML result for the same call.

<ResultSet ... >
  <Result precision="city">
    <Latitude>34.05217</Latitude>
    <Longitude>-118.243469</Longitude>
    <Address></Address>
    <City>LOS ANGELES</City>
    <State>CA</State>
    <Zip></Zip>
    <Country>US</Country>
  </Result>
</ResultSet>

One way to get from JSON to a JavaScript object is to call eval(), with the string as argument. The following sample uses the Geocoder result to display LA’s Latitude and Longitude in an alert box. This is just static.

eval.html
<HTML>
  <BODY>
    <script language"javascript">
      var location = eval({"ResultSet":{"Result":[{"precision":"city","Latitude":"34.05217","Longitude":"-118.243469","Address":"","City":"LOS ANGELES","State":"CA","Zip":"","Country":"US"}]}});
      alert("Lat:" + location.ResultSet.Result[0].Latitude + " Lon: " + location.ResultSet.Result[0].Longitude );
    </script>
  </Body>
</HTML>


This is nice but doesn’t do too much in the real world. The problem was to get the data from a Web service that is located on another domain imported without using a proxy.

The secret sauce

Adding the <Script> tag dynamically in the DOM tree of the browser is the answer and the JSON response helps to get the data in a format that is easy to digest for JavaScript. When a Script tags gets dynamically added to the DOM tree the code (script URL) gets executed on the fly. The trick is that instead pointing to a JavaScript library, we include a Web service request in the tag that returns data in the above mentioned format. The Yahoo! Web services that offer the JSON output option also supports a parameter called ‘callback’ and all it does is wrap the return data in a function with the name of the callback value. http://api.local.yahoo.com/MapsService/V1/geocode?appid=dantheurer&location=la&output=json&callback=getLocation would result in something like this getLocation({"ResultSet":{"Result":[{"precision":"city",....) which tries to call the getLocation function (callback) that needs to be implemented to deal with the data.

Below is a sample that takes a location as an input parameter, then calls the Y! Geocoder WS and displays Long / Lat in the page.

geocodeJson.html
<script type="text/javascript" src="jsr_class.js"></script>
<script type="text/javascript">
  //<![CDATA[
  var appid = "dantheurer";

  //That is the callback function that is specified in the request url and gets executed after the data is returned
  function getLocation(jData) {
    if (jData == null) {
      alert("There was a problem parsing search results.");
      return;
    }
    //get the values out of the object
    var lat = jData.ResultSet.Result[0].Latitude;
    var lon = jData.ResultSet.Result[0].Longitude;
    //build some html
    var smart = "Long: " + lon + "<br />" + "Lat: " + lat;
    //add it in the page DOM
    document.getElementById(’result’).innerHTML = smart;
  }

  function addGeocode() {
    var location = document.getElementById("geoquery").value;
    // Build the Yahoo! web services call
    request = 'http://api.local.yahoo.com/MapsService/V1/geocode?appid=' + appid + '&location=' + location + '&output=json&callback=getLocation';
    // Create a new script object
    aObj = new JSONscriptRequest(request);
    // Build the script tag
    aObj.buildScriptTag();
    // Execute (add) the script tag
    aObj.addScriptTag();
  }
  //]]>
</script>


Jason, my cube neighbor, wrote a really nice class that deals with the dirty work of adding, removing and making sure the tags are unique. If you open up the file, it even has a security warning from the inventor of JSON in there. Below is the code snippet:

jsr_class.js

function JSONscriptRequest(fullUrl) {
  // REST request path
  this.fullUrl = fullUrl;
  // Keep IE from caching requests
  this.noCacheIE = '&noCacheIE=' + (new Date()).getTime();
  // Get the DOM location to put the script tag
  this.headLoc = document.getElementsByTagName("head").item(0);
  // Generate a unique script tag id
  this.scriptId = 'YJscriptId' + JSONscriptRequest.scriptCounter++;
}

// Static script ID counter
JSONscriptRequest.scriptCounter = 1;

// buildScriptTag method
JSONscriptRequest.prototype.buildScriptTag = function () {
  // Create the script tag
  this.scriptObj = document.createElement("script");

  // Add script object attributes
  this.scriptObj.setAttribute("type", "text/javascript");
  this.scriptObj.setAttribute("src", this.fullUrl + this.noCacheIE);
  this.scriptObj.setAttribute("id", this.scriptId);
}

// removeScriptTag method
JSONscriptRequest.prototype.removeScriptTag = function () {
  // Destroy the script tag
  this.headLoc.removeChild(this.scriptObj);
}

// addScriptTag method
JSONscriptRequest.prototype.addScriptTag = function () {
  // Create the script tag
  this.headLoc.appendChild(this.scriptObj);
}


Here is what the script does in some bullet points

• Build request URL with input parameter and callback function
• Build the script tag that contains the request URL
• Add the new tag to the DOM tree
• As soon as the tag gets addes, the WS request gets executed and what gets returned is the JSON response wrapped in a function call. The name of the function got specified in the callback parameter.
• The response, which is a function call now calls the matching function with the JSON data as parameter. This is where the data can get extracted.
• The script tag gets removed again

The sample I wrote for the Maps launch depends on a PHP proxy. I took that sample and wrote a version that uses JSON instead. Maybe it's because it's new, but for some reason I like the new version better.

All this is not just a hack that might not work again tomorrow because of a browser upgrade. Most of the dynamic ads use the dynamic script tag to display themselfes depending on the context. There are of course ups and downs for both technologies and not everyone agrees, but here are some points to think about.

Proxy method

• More robust, error handling is easier
• More control on the server side
• It has some security implications on the server side as the proxy could be abused.
• The server side can have additional functionality implemented that is hidden to the caller e.g. login, exchange secrets...

Dynamic script tag

• No XML parsing necessary
• Performance win
• No traffic gets routed (and counted) on your end.
• JSON converters don't know that they should define an array if they is only one nested element in a tag, even if the Schema allows 1..n
• More cross-browser issues
• Positive impact on rate limiting if it's done per IP
• No need to set up a proxy

For more information about JSON, JavaScript and Web services have a look at our brand new Yahoo! Developer Network JavaScript Developer Center.

This post will discuss the following parts needed for the Mash-up:

• Map API that lets you embed a map into your website
• Data source
• Ways to get around cross-domain restriction

There are a couple of choices for embeddable Maps out there. The “oldest” one is Google Maps, but there is also Virtual Earth, and today the new Yahoo! Maps launched! This is really good stuff. Yahoo! offers different ways of working with their Maps.

• The simple API takes a geoRSS formated XML file and overlays the data on yesterday’s YMaps technology
• There are three ways to interact with the brand new Flash Maps. One of them is JavaScript, making it really easy to write super slick applications
• The last one is an AJAX API that works pretty similar to what’s already out there.

The sample is located at http://theurer.cc/maps/y/ and you can have a look at the JavaScript code by viewing the page source. It uses the AJAX API and demonstrates the following:

• Geocode an address and display on the map
• Overlay Traffic information like accidents and construction zones
• Overlay local search information

The data sources used are three REST Web services that Yahoo also recently opened up. They are easy to program against as it is just a URL with parameters that returns XML.

Browsers like Firefox and IE enforce a cross-domain restriction, which does not allow HTTP calls from one domain to another. Since REST works over HTTP and the services are not hosted on the same server as the Maps application, we need to find a way to get around that. There are different ways to do that.

• Software proxy
• Apache mod_rewrite
• Dynamically loading .js files via script tag and pass data instead of JS code.

The easiest approach is to write a proxy that lives on the same server as the application and just pass the Request and Response to and from the web server. This has a slight security risk, but the example shows how you could limit it. For our scenario it works perfectly.

Those were the basics. Let’s look at some code! The full source:

<html>
<head>
  <script type="text/javascript"
src="http://api.maps.yahoo.com/ajaxymap?v=2.0
&appid= dantheurer"></script>
  <style type="text/css">
    #mapbox {
      height: 600px;
      width: 600px;
  } </style>
</head>
<body>
  <div id="mapbox"></div>
  <script type="text/javascript">
    //init map
    var ymap =
    new YMap(document.getElementById('mapbox'));
    //define a point to start at
    var startPoint = new YGeoPoint(37.34,-122.02);
    //center and draw map at given point
    ymap.drawZoomAndCenter(startPoint, 7);
  </script>
</body>
</html>


The appId in the script is included only for tracking purposes. Please replace it with your own. You can get an appid here. Once you have the code working, we can go ahead and add controls to the map.
//init map
var ymap = new YMap(document.getElementById('mapbox'));
//add controls
ymap.addPanControl();
ymap.addZoomLong();
…

All that and more can be found in the GettingStartedGuide for AJAX. It gets a little more interesting when data sources come into play. For this sample, I demonstrate the easiest way to overcome the cross-domain restriction. A PHP file will serve as a proxy. Yes, this has some security implications but the proxy is limited to a request with a specific (Yahoo!) domain. For the use case of a free Web service, this is “good enough”. This is all that’s needed:

yproxy.php
<?php
  header("Content-type: text/xml\n\n");
  $url = $_SERVER['QUERY_STRING'];
  //strpos allows only calls to specified endpoint
  if ( strpos($url,"http://api.local.yahoo.com/") === 0)
  {
    $ch = curl_init($url);
    curl_exec($ch);
  }
?>

To run the proxy, the PHP Curl extension needs to be enabled.

Now that the proxy is in place we are able to make a REST call to api.local.yahoo.com. I want to follow what happens if the ‘AddLocation’ Button is pressed. The sample has an input box where the user can input an address.

<div class="inputelement">
<button onClick="addGeocode()">
Add location</button> <input id="geoquery"
value="5th Avenue,New York" size="50">
</input> - enter an address</div>


Once the button is pressed, the function addGeocode() gets called. Yes, the name could be better… and what it does is assemble the REST query and call the function that actually calls the proxy.


var query = document.getElementById("geoquery").value;
var uri =
"http://api.local.yahoo.com/MapsService/V1/geocode?
appid=dantheurer&location=" + query;
callWS(uri, "geocode");


The callWS() does an XmlHttpRequest to the proxy with the REST URL as parameter and displays ‘Loading’ while it waits for the proxy to complete the request. The PHP proxy uses CURL to make the actual request, and the callback method parseResult() gets executed once the call has succeeded.

var url = 'yproxy.php?' + encodeURI(target);
xmlhttp.open('GET', url, true);
xmlhttp.onreadystatechange = function() {
  if(xmlhttp.readyState == 4 && xmlhttp.status == 200) {
    document.getElementById('result').innerHTML = '';
    parseResult(xmlhttp.responseText, service);
  } else {
  document.getElementById('result').innerHTML =
  "Loading...";
  }
};
xmlhttp.send(null);
}


From here, all that’s left is parsing the XML and adding the markers. In this sample I used the xmlw3cdom.js parser from SourceForge. It’s more than I need, but it makes things really easy. This DOM parser requires the following SAX parser xmlsax.js to deal with the XML object. I will not discuss how to parse the XML, because it’s easier to just look it up in the source file.

The results are used to create a Point and a String for the Smartwindow, which get passed to the createYMarker() method.


var point =
new YGeoPoint(parseFloat(lat),parseFloat(lon));
var smart = "Long: " + lon + "
" + "Lat: " + lat;
var myMarker = createYMarker(point, i, smart);


It creates the Markers on the map.


var marker = new YMarker(point,'id'+number);
marker.addLabel(number);
YEvent.Capture(marker,EventsList.MouseClick, function() { marker.openSmartWindow(msg) });
return marker;


This is a pretty simple example but this can be the foundation for a much more complex mash-ups. Once this part is done, it only gets better.

Keep mashing!

On the first look the Virtual Earth API appears to be pretty similar to what Google offers. That’s quite nice but why was it necessary to switch (long, lat) to (lat, long) if everything else looks so much the same? A really nice thing is that you don’t need to register your application or generate a key to use the API.

There biggest difference between the two API’s is that Virtual Earth only offers one class (VE_MapControl) which is the equivalent to GMap but that’s all there is. If you want to overlay information you can call a method of the class called AddPushPin() and that is not a great way to do it. What I really like a bout the G-Implementation is that I can create little “pin-objects” place them on the map and add a listener to it. This is really helpful to actually make you map interactive without writing a lot of code. VE also provides no default control to zoom in or out.

Here is my attempt to create something quickly that offers the same set of features then my Google Maps demo. I didn’t have the time to create any controls, therefore it is not really useful. (I will be late for my hockey game!)

To sum this up, the maps API doesn’t seem to be very polished. VE only comes with the bare minimum of features which seems to me like it was done in a big hurry. I would not be surpised to find to missing classes in the documentations in the next couple of weeks.

Update: Just realized that double-clicking on the VE Maps zooms in and that the satellite data for Europe is much worse than Google’s…