Author: Rob Yates

Opensocial and OAuth specs

The REST api for opensocial makes its appearance in opensocial 0.8. The specification references some other specifications that are also worth a look.

OAuth Consumer Request – This is proposed as the means for server to server authentication between the Consumer site and the Service provider. It has the potential to replace basic auth over SSL which is the only real standards based approach for securely authenticating using a shared secret, given that digest was underspecified.

XRDS-Simple – This also looks promising and it is tackling the whole xri / yadis discovery mess that openid 2.0 seems burdened with.

Alan Greenspan’s Age Of Innocence

Alan Greenspan: Japan in recent years has had to struggle back from the stock-market and real estate crash of 1990. Japanese banks became heavily invested in loans backed by real estate as collateral, as real estate prices soared. When the turn came and prices cascaded downward, the collateral became inadequate. But instead of calling the loans, as most Western banks would do, the bankers refrained. It took years and many government bailouts before real estate prices stabilized and the banking system returned to normal lending, with realistic estimates of bad loans and, hence, capital.
I concluded from this that Japan behaved differently from other capitalistic countries.

Really? Sounds fairly familiar.

Blocked by Google

Several folks have told me recently that Google is identifying my site as evil. I assure you it isn’t, however I know why google has flagged it. A couple of weeks ago my site was hacked and a hidden iframe was introduced. I cleaned it up, changed my password, upgraded wordpress and even changed the theme. All should now be well.

I have contacted google and we’ll see how long it takes to no longer be flagged as ‘Evil’.

Scaling Databases and Google’s App Engine

Assaf Arkin: if anything I wrote sounds vaguely familiar because you somehow managed to dumb your RDBMS into storing structured data in BLOBs, added versions and timestamps on all records, grappled with minimizing transactions and locks, denormalized data like there’s no tomorrow, or relied too much on a message queue, then time to rethink. Are you using a hammer to polish your china? (Tip: not a good idea, invest in soft cloth)

I know I am late (particularly as an IBMer) to the whole couchDB / bigtable thing, but I have to admit that until I read Assaf’s article I didn’t really understand what all the fuss was about.

I also didn’t understand the fuss about google’s app engine and shared the view that it looked like “The World’s Worst Webhost“. My current webhost lets me run ruby, perl, php and python with either mysql or postgres, so why would I want to limit myself to python and some proprietary, lock-in database. The answer is, of course, scale.

And so here is the dilemma. If you are developing a new web application from scratch what do you do if you think / hope that one day you will be wildly successful? There is the flickr / facebook / myspace path i.e. use a single relational database till it breaks, then use master / slave and then shard (gory details for myspace) and now there is the google app engine path i.e. build the application from the start in a way that is guaranteed to scale out with no herculean efforts.

This is not an easy choice. The problem with the google path is that their datastore has no joins, limited transaction support and some random query limitations. Now, I have never built an application with those limitations, but I would guess that it takes longer to build and requires a whole new way of thinking.

The google app engine path seems difficult to justify for a new app. It’s built on the premise that the app will be wildly successful and most web apps aren’t. Justifying the additional upfront expense to investors / management won’t be easy and given that many big names have already successfully traversed the other path, it may be better to start by choosing one of the world’s better webhosters and only invest in scaling the db when the money starts rolling in.

Thin Ice

Paul Volcker: So I think we are skating on increasingly thin ice. On the present trajectory, the deficits and imbalances will increase. At some point, the sense of confidence in capital markets that today so benignly supports the flow of funds to the United States and the growing world economy could fade. Then some event, or combination of events, could come along to disturb markets, with damaging volatility in both exchange markets and interest rates.
[snip]…
What I am talking about really boils down to the oldest lesson of economic policy: a strong sense of monetary and fiscal discipline.

Volcker wrote that in 2005, central bankers and government ignored him then as they do today.

Email Addresses as Openids

Eran Hammer-Lahav: Users should be able to use their email address as their OpenID, as most sites today use emails as usernames anyway. This will solve the first part of making the identifier simple. So instead of choosing ‘AOL as the identity provider and entering the screen name, or worse, typing ‘http://openid.aol.com/username’, the user will type ‘username@aol.com’.

This can’t happen soon enough and there’s a detailed promising proposal behind it. Further discussion here.

Powered by ScribeFire.

Facebook – an Openid challenge

Facebook exists because a simple usable federated identity system doesn’t. Wired’s challenge to tear down the social networking silos seems easier to solve if we had such an identity system and I would think that the openid community would take up the reins and lead the charge.

I was therefore somewhat aghast when I saw the original mr. openid and the current mr. openid trying to solve the problem without actually building atop openid. Why? Have they abandoned their offspring? Or is Openid just not the right foundation and in need of a reboot?

The wired article points out that it’s pretty trivial to assemble facebook as long as you don’t mind the entire world seeing what you are doing, your "friends" can even receive event notifications via feedreaders, but then so can the rest of the world. Facebook’s real value, therefore, is an easy to use access control system, limiting who can view your photos, view your posts and get alerts. This access control system, dubbed the "social graph", is embodied as "friends" in facebook and "connections" in linkedin. 

So why can’t openid enable this in a distributed fashion?  Surely openid should be the basis of any distributed access control system. Why can’t I, who chooses to be hosted on facebook, befriend you on myspace. Why can’t I receive notifications of your recent actions? and why can’t you view my profile? and why can’t all this happen without the prying eyes of the rest of the world?  These seem like the problems that openid should be helping solve. So why didn’t Brad and David choose to build atop it? instead making it’s use optional?

I have to admit to worrying a little about openid’s direction. It can’t get close to the challenge thrown down by Wired and instead of trying to address these very real problems in version 2.0 it has instead chosen to focus on incorporating an obscure naming scheme, which IMHO has introduced unnecessary complexity.  So what could it do? Could the Wired challenge be solved with openid as the base?  I believe the openid community could choose to solve these problems and FWIW, here’s my list of to do’s.

  1. Adopt the world’s most popular naming scheme for individuals.  Yes I know there are privacy issues with using an e-mail address identifier and yes I know there are advantages to http based URI’s, but there is a reason why it is facebook’s primary identifier.  Ignoring it presents real usability and adoption challenges.
  2. Have openid work for REST based web services e.g. feed readers.  The only way that friends can keep track of my latest posts / photos etc. in a distributed fashion is through feeds and if I want to limit who can see them then the feed readers need to authenticate with my service.  Unfortunately openid is designed for interactive user agents and feed readers are anything but that. So please can we have openid designed to work with any http client and not just the "interactive" ones.
  3. Define the "befriend" protocol.  This would be the mechanism that establishes and terminates the relationship between two identities, so they can view each others stuff. Instant messaging has this same problem i.e. establishing who can view my current presence and so there are places to look for inspiration.

Am sure there’s more details e.g. how the "roster" of friends gets sent to the different services but that also sounds familiar. It just seems to me that Brad and David are applying a band aid with their proposal and I’d much prefer they go back to open heart surgery and fix this thing once and for all.

Openid reboot? hmmm, interesting, and if you read the entire thread, blush

p.s. I don’t buy Dave Winer’s economic roadblocks to distributed social networks.  The same argument could be applied to AOL’s and Delphi’s email "walled gardens" prior to 1993.

Worlds Apart – Why Java needs ahead of time compilation and why C# has it

Michal Cierniak – In my opinion modularity will not bring significant performance wins.  I agree, but that’s not the point.  Java needs modularity and ahead of time compilation so that it can start fast and share memory between processes, otherwise Steve Jobs has a point.

I don’t hear many folks, that run Java applications, complaining that Java’s performance is poor once the application is running.  However they do complain that the applications take a long time to start and that when running many Java applications LOTs of memory is consumed.  I work for a company that makes use of three significant java applications.  No one would claim that they start fast, but my biggest complaint is that these three applications, that are all built on the same code base, share no memory at runtime, none, zip, nadda, nothing.

It’s like we have gone back 40 years in computing history.  There used to be a time that programs didn’t share any memory but that went away with the introduction of dynamic linking and shared libraries. Most programs use DLLs (Windows) and Shared Objects (Unix) to ensure fast startup and efficient memory sharing and all of this is managed by the OS.  If two concurrently running programs both decide to use the same spell checking library then that library is memory mapped into the address space of the two programs by the operating system i.e. there is only one copy resident in memory. In java this is not true, there is a unique copy resident in each address space.

So why can’t Java programs share memory given that shared libraries are a technology that’s been in widespread use for at least 25 years? It’s really for two reasons.  The first is that up until this point there has really been no way to define a shared library in Java i.e. here’s a bunch of code and here is its external interface. JSR294 (modularity for Java) addresses this point.  The second is that Java has no efficient AOT compilation and so unlike most other statically typed languages it can’t utilize the traditional OS functions to load and share its libraries. I have belabored this point in the other "Worlds Apart" posts here and here, pointing out that this is a key differentiation for CLI implementations such as .net or mono.  Miguel (mono lead) also has an excellent post that provides a good overview of mono’s AOT support and the rationale behind it. JSR294 could be designed in such a way to provide for efficient AOT, and I belabor this point here.

It’s also not like the problem of memory sharing and startup isn’t well understood in the Java world. Sun produced a paper 5 years ago trying some crazy dynamic memory sharing thing and followed that with a paper the very next year that deduced instead that shared libraries were the way to go as the first "dynamic" approach "required complex engineering" while using shared libraries was "simpler" and "relies on existing software and OS mechanisms".

However the opportunity to produce shared libraries from Java code has not been seized upon (IMO it’s too hard with custom classloaders) and there have been many other attempts at sharing memory in Java, non of which have yet proven successful. C# and CLIs, which were developed with the benefit of experience with JVMs, made efficient AOT a priority and reap the benefits of faster startup and better sharing.

So why not take the opportunity that JSR294 is providing and level the playing field with CLIs by using it to provide efficient AOT for Java that in turn allows Java code to compile to shared libraries? As a result Java will start faster and share memory between processes.  Without this CLIs will maintain a significant advantage and they have enough of those already.