Tag: portability

Online identity, relationships, Google, and Social Graph API

Web Worker Daily covers the release of Google Social Graph API. These are pretty exciting news.

With so many websites to join, users must decide where to invest significant time in adding their same connections over and over. For developers, this means it is difficult to build successful web applications that hinge upon a critical mass of users for content and interaction. With the Social Graph API, developers can now utilize public connections their users have already created in other web services. It makes information about public connections between people easily available and useful.

Even better news are that one of the systems supported by Google is XFN – XHTML Friends Network. This is exactly the same XFN that you see mentioned in your WordPress administration. When you manage blogroll (links) of your site, you can attach different XFN attributes to each link. The screen looks something like this:

WordPress XFN editor

If your web site also uses one of the properly built WordPress themes, which has profile=”http://gmpg.org/xfn/11″ attribute set in the HEAD tag (see XFN join page for more information), then you are all set to go. Google will index XFN information from your site and will make it available via its Social Graph API.

It’s good to see Google stepping into this area. It brings a lot of public attention to a very useful area of our online lives. Soon, we’ll see more social tools and services like rubhub and Plaxo Pulse.

Portability and flexibility win over performance

I noticed this ticket in WordPress Trac – Change enum to varchar and went in to see if there is any heated discussion.  The issue is around field types used in SQL scheme for WordPress tables.  Certain fields, such post status employed ENUM type with a set of allowed values.  The proposed change in the ticket is to convert them to VARCHAR type.

Why the change?  Well, VARCHAR is just a text field.  Anyone can put pretty much any string into it.  It has more flexibility for plugin developers and future changes – no need to tweak the SQL scheme.  ENUM on the other hand works a little bit faster.

Side note: I also thought that ENUM provides some extra data validation, assuming the ENUM field is set to NOT NULL, but it turns out this is not the case.  If you insert a record with a value which is not in the list, the NULL is used. 

The change has been approved, the patch was attached, and the world will see it in the next WordPress release.  Once again, it has been proven that human time is much more valuable than machine time.  Making it easier for plugin developers to extend and change the system has more value than that of a few extra CPU cycles to lookup in strings instead of numbers.