I logged into Facebook today and I saw a new person under "People You May Know." This person is someone I know from refereeing hockey here in Arizona. It turns out that I only have one person on my friends list who I know happens to be an ice hockey referee, someone I know from not only refereeing but also playing hockey, more than 10 years ago. When I clicked on Jeff's profile (the new person Facebook suggested), I saw he only had two friends - his is a very new profile!
Jeff and I haven't ever emailed back and forth directly. I've sent a couple email blasts, and he probably has as well. But that's the extent of it.
My best conclusion is that Jeff allowed the Facebook friend-finder application to have access to his email. Because I'm on the same refereeing email distribution list as Jeff, I can only assume that Facebook has looked at his email and decided to inform me that I might know Jeff.
I do appreciate the flexibility of Facebook's find-a-friend tool. But for it to be telling me that Jeff might be my friend based on data he provided seems to be a mild form of information leaking.
I'm only hoping that he provided his information to the Facebook friend finder tool. I never did. And if he didn't, well, now I'm concerned that Google and Facebook have been sharing that kind of information anyway...
Tonight I’m publishing to Codeplex a project that I’ve been working on for about a month, that I’ve called OpenGraph.NET. It’s a C# client for Facebook’s still-new Graph API. It currently supports regular desktop applications, web sites (using Web Forms and ASP.NET MVC), and to some extent, Silverlight. All of the groundwork is there – it’s just going to take a bit more work to get it across the finish line. I’m calling it version 0.9.1 "Beta”. (Maybe I’ll come up with some clever name like “Froyo,” like the operating system on my phone).
OpenGraph.NET’s documentation is available at http://robpaveza.net/opengraph.net/docs/ and the project can be downloaded from CodePlex at http://opengraph.codeplex.com/. There are also a couple demos on the CodePlex site within the download.
OpenGraph.NET is licensed with the new BSD license – basically, you can use it for whatever you want, but if you hand out the project publically, either compiled or as source code, you should include a copy of my copyright notice and license terms. I’m not an advocate of copyleft, but I would certainly welcome patch submissions. Over the weekend, I’ll be porting the source code repository from my web server onto CodePlex.
One more note – it IS indeed working out there. We’re using it on a currently-undisclosed project at Terralever for an event being hosted by one of our clients, and I am using the Real Time Updates handler for it as well.
Over the coming weeks, I’ll be talking about the internals of how this works, including dynamic methods.
I’d like to mention a big thank-you to James Newton-King, for the awesome Json.NET library which is used extensively throughout OpenGraph.NET.
I’ve officially launched the Facebook UI for ASP.NET project at CodePlex at http://facebookui.codeplex.com/. It’s kind of a preview edition of what’s to come – and there’s quite a bit. Here’s a quick overview:
- Design-time and run-time server support for about 30 FBML controls.
- Visual Studio IntelliSense support for FBML controls
- Web Site project templates in Visual Studio 2008
- All FBML tags within: Users/Groups, Profile-Specific, Embedded Media, Visibility on Profile, Tools, Forms, Message Attachments, Additional Permissions, Notifications and Requests, Status Messages, Page Navigation, Dialog, and Wall sections.
- Complete API support.
- Extensibility points within the FBML controls framework and API framework to enable updates from Facebook to be rolled in without requiring an immediate release of a new library.
- LINQ-to-FQL (or as some folks at the user group mentioned, perhaps it’ll be called LINQ-to-Facebook).
- Higher-level controls will be included, such as validators and simple logic controls, like a birthday display.
- Facebook internationalization should be supported.
- Mobile platform support should be extended.
Beyond that, I’m not sure where we’re going to take the project. We’ll have to see!
On March 10th, I’ll be presenting an ASP.NET control library for Facebook at the Phoenix ASP.NET Users Group. Among other things, we’ll be talking about how to create a Facebook application using ASP.NET, debugging aids, and the Facebook API. Along with that, Terralever will be releasing our library to the open-source community on Codeplex. (This post will be updated once we’ve done so).
The library is currently in varying degrees of maturity. We’ve got about half of the FBML controls supported in the library with full design-time support:
If you haven’t worked with Facebook before, aside from having design-time support, the best part about having Facebook controls with runat=”server” on them is that you have full access to them in codebehind. Because of the way Facebook controls are accessed (using the XML fb: prefix), we couldn’t do that before without causing exceptions because ASP.NET would try to access them. That generally led us to using ugly ASP.NET databinding syntax:
<fb:name usereflexive=”true” useyou=”true” capitalize=”true” uid=’<%# Eval(“FbUserID”) %>’ />
We still have the ability to use this type of syntax, but we have the flexibility to do specific databinding (for instance, within a repeater control), accessing that control within a type-safe way.
There are a few big differences, though. Facebook has this concept of a meta-control called fb:else; it’s used in conjunction with several other controls (such as the one shown in the screenshot above). But that’s DEFINITELY not supported in the ASP.NET code editor, and it’s fairly irregular for an ASP.NET application. Fortunately, we already have a way around that problem, templates:
By using designer templates we’re able to provide that metadata to the editor. (More on that before too long).
For the release in early March following the user group presentation, we’ll release a subset of the FBML user controls (the Terralever.Facebook.UI.FbmlControls namespace) to the community, as well as some base-level utility classes, such as base classes for Canvas- and IFrame-based pages. Hopefully, there will also be a preview of LINQ-to-FQL, although that’s not necessarily going to happen. Debugging aids, including specialized and extended tracing HTTP modules, will be part of the release. We’ll also include a couple controls we’ve had to model, including a Pager control, a Birthday List control, and a control template for hosting on user profile boxes.
Additional FBML controls will be added as time goes on, but the second biggest release is going to be adding support to the Terralever.Facebook.UI.CanvasControls namespace. Just like the System.Web.UI.WebControls namespace is to the System.Web.UI.HtmlControls namespace, .CanvasControls is to .FbmlControls. It provides support for some of the higher-level functionality that we’ve come to expect from ASP.NET. If you’ve tried to use the normal validation controls on a Facebook Canvas page, you’ve known the bitter defeat of it. I’m not so sure it’ll get to some of the more data-centric controls we’ve come to know and love, like DataGridView (because let’s be honest – it just doesn’t fit into a Facebook page). But we’ll see some support for postbacks (on that note, Microsoft, ClientScriptManager shouldn’t be sealed and Page.ClientScript should be virtual), all the regular validator controls, and some Facebook-friendly client UI controls.
We’ll include much greater support for the Facebook REST-based API. I haven’t decided yet whether we’ll consume them as WCF services or simply use an XML parsing strategy, such as LINQ-to-XML. It it isn’t already included, we’ll definitely include a LINQ-to-FQL implementation.
Long-term (version 2 and beyond) will most likely add support for the Facebook internationalization platform, the Editor control, and the Mobile platform. We’ll see how it goes and what is requested by the community.