Springtime is in full swing as the fragrance of blossoming flowers fills the air, newborn bunnies gather in the backyard to nibble on clover, and pilots flock to the Garmin website for… software updates?
The Google+ project brings the nuance and richness of real-life sharing to software. The Google+ platform brings that nuance and richness to all of the web. We started with Google’s own products, added the +1 button for site owners and content publishers, and introduced games from a handful of partners. That’s just the beginning though — we want every one of you who builds applications to be able to include rich sharing, identity, and conversations in your app. Today, we’re taking the next step on that journey by launching the first of the Google+ APIs.
Let’s Go Public
Google+ gives users full control over their information, supporting everything from intimate conversations with family to public showcases and debates. This initial API release is focused on public data only — it lets you read information that people have shared publicly on Google+. For example, if you want to get my profile information, you can use the people.get method by sending the following HTTP request:
which returns the following JSON encoded output (excerpted for brevity):
"displayName": "Chris Chabot",
"name": "Google+ Developer Relations",
"title": "Developer Advocate & Manager",
Similarly, you can get a list of my most recent public posts by using the activities.list method:
Because we’re starting with public data only, you simply need to register your app before making requests. And if you aren’t yet sure which Google+ user is running your app (for example, because they’re installing it for the first time), then you can use the new plus.me OAuth2 scope to ask the user who they are.
On The Shoulders of Giants
We love the way the programmable web has evolved, so we’re using existing standards and best practices wherever we can:
In addition, since most of us no longer write raw HTTP requests these days, we provide libraries for your favorite language: Java, GWT, Python, Ruby, PHP, Objective-C, and .NET. These libraries are all open source, so we’d love to have your feedback and help with them.
You can find more information about the Google+ platform, including today’s new APIs to public data, at developers.google.com/+ on our new Google Developers site. This site will be the place to go for access to documentation, terms and policies, discussions with other developers, tools that make development on the +Platform easier and more fun and, of course, the place where announcements concerning new releases will be made.
Included in our policies are three simple guidelines that we aspire to in our own products, and that we’d like all applications built on the Google+ platform to follow also: put the user first, be transparent, and respect user data. The goal behind these guidelines, as with all of the features and fine print, is to work together to build products that our users will love.
And now …
For all of you developers who have been asking for a Google+ API, this is the start. Experiment with it. Build apps on it. Give us your feedback and ideas. This is just the beginning; the Google+ platform will grow and we value your input as we move Google+ forward.
I came across a curious error earlier today when attempting to use a SqlDataReader to read a column of geometry data from a SQL Server table:
System.InvalidCastException: Unable to cast object of type ‘Microsoft.SqlServer.Types.SqlGeometry’ to type ‘Microsoft.SqlServer.Types.SqlGeometry’
SqlGeometry to SqlGeometry… you’d think that would be a pretty easy cast, wouldn’t you? It turns out that this is a problem caused by a conflict between the spatial libraries used in SQL Server Denali compared to that in 2008/R2, and you’ll get this error depending on which version of Microsoft.SqlServer.Types.dll you use, and how you try to access geometry or geography columns from a datareader:
// This works in SQL Server 2008/R2, but errors with Denali
SqlGeometry g = (SqlGeometry)dataReader["GeomCol"];
// This works in Denali, but not in SQL Server 2008/R2
SqlGeometry g = SqlGeometry.Deserialize(reader.GetSqlBytes(0));
// This works in Sql Server 2008/R2/Denali
SqlGeometry g = new SqlGeometry();
After a bit of digging around, it appears that using GetValue or square brackets notation  to access a geometry/geography field in a SqlDataReader is hard-coded to load the 10.0 (SQL Server 2008) version of the Microsoft.SqlServer.Types library.
If you’ve got side-by-side installations of both SQL Server 2008/R2 and Denali (as I have), and try to reference the 11.0 (Denali) version of Microsoft.SqlServer.Types, you’ll therefore get an assembly mismatch when both versions of the library are loaded, which causes the slightly unhelpful error listed at the top of this post. Even if you’ve only got Denali installed, your code may still try to reference a (non-existent) 2008/R2 version of the Microsoft.SqlServer.Types.dll library, so you’ll get a different error instead:
Could not load file or assembly ‘Microsoft.SqlServer.Types, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91′ or one of its dependencies. The system cannot find the file specified.
The simplest way to resolve these errors is by changing the way you reference any geography/geometry (and, I imagine, hierarchyid) columns from your DataReader, as in the code example above. Alternatively, you can set up an assembly redirection in the application configuration file as explained here (about halfway down), which will allow you to correctly target the Denali version.
As per the What’s new in SQL Server Denali whitepaper, “… side-by-side installations of SQL Server Code-Named “Denali” CTP1 and CTP3 are not supported with existing SQL Server 2008 installations …”, so perhaps I only have myself to blame for this. Interestingly though, the person who raised this MS Connect issue, says that they have experienced exactly the same problem on a clean install of Denali CTP3. The response from Microsoft suggests that this may be due to older versions of the library being packaged with Visual Studio 2010, and also confirms that the problem will not be resolved prior to RTM of SQL Server Denali.
Strangely, I encountered another curious error a few months ago concerning version conflicts of Microsoft.SqlServer.Types. My CTP3 Management Studio Spatial Results tab does not plot curved geometries (selecting a CircularString or the result of BufferWithCurves etc. just produces a blank pane). I had originally assumed that, since this was only a CTP release, this feature had simply not been added yet. It turns out that curved geometries are supported in SSMS CTP3 Spatial Results tab but, if you have side-by-side SQL Server 2008 and Denali, this can corrupt this feature. I guess the reason is similar – that SSMS is somehow attempting to load the SQL Server 2008/R2 version of Microsoft.SqlServer.Types, which, of course, doesn’t support curved geometries.