LLVM continues it’s quiet ascent. It now has two jdks, two clis, python (and by that I mean the real python), ruby and php running on it. Not bad for a compiler / runtime who’s main goal is to be apple’s main compiler for static languages (C, C++ and Objective C).
Ignore at your peril.
One of the more frustrating aspects of calendaring systems is that the freebusy lookups are all proprietary. Meeting invitations can be sent from one system to another (assuming you know a time to meet). However, it is not possible to lookup when someone from Lotuslive, someone from gmail and someone from Yahoo are all available to meet. In the corporate space this type of scheduling is invaluable.
The format for looking up someone’s freebusy time is included in a standard that was completed in 1998, but they punted on all the hard stuff. The hard bit, as I have mentioned before, is working out where someone’s freebusy is stored on the web and then authenticating with that store in a manner that can be verified. WebFinger and OAuth are now putting the complete round trip within spitting distance.
Below I’ll propose an approach to scheduling a meeting with my mom (who uses gmail) from LotusLive (which I use). I will be rob@robubu.com (but using LotusLive for my calendaring service) and my mom is mom@gmail.com. We’ll also assume that my mom has told google that it can share her calendar free time data with any one in her contact list and that I am in her contact list.
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Subject>acct:mom@gmail.com</Subject>
<Alias>http://www.google.com/profiles/mom</Alias>
<Link rel='http://portablecontacts.net/spec/1.0'
href='http://google.com/api/people/' />
<Link rel='http://ietf.org/icalendar/freebusy'
href='https://google.com/api/calendar/mom/freebusy/' />
</XRD>
From this LotusLive can now determine that my mom’s freebusy endpoint is at https://google.com/api/calendar/mom/freebusy/. It concludes this by looking for the link with a rel attribute of http://ietf.org/icalendar/freebusy
https://google.com/api/calendar/mom/freebusy/
?opensocial_viewer_id=rob@robyates.com
&xoauth_public_key=https://lotuslive.com/keys/publickey.crt
&oauth_signature_method=RSA-SHA1
&oauth_signature=djr9rjt0jd78jf88%26jjd99%2524tj88uiths3
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Subject>acct:rob@robubu.com</Subject>
<Link rel='IDP' href='
https://lotuslive.com' />
</XRD>
I know this is not perfect and I know there are probably a fair amount of changes that are needed, but I wanted to jot down something that, I think, is fairly close to a workable solution. Am very interested in other’s thoughts.
p.s. WebFinger on email addresses does provide a means of discovering valid email addresses, but no where near as much as this does. The fight against spam can’t center on not making email addresses discoverable.
Hardware-assisted virtualization: Hardware-assisted virtualization was first introduced on the IBM System/370 in 1972, for use with VM/370, the first virtual machine operating system. Virtualization was eclipsed in the late 1970s, with the advent of minicomputers that allowed for efficient timesharing,
George Santayana: Those who cannot remember the past are condemned to repeat it
My first I.T. job right out of university was as a DBA on an IBM mainframe for a large british retailer. That mainframe ran at near 100% cpu all day. The thing was amazing. It ran lots of different workloads. It ran web like applications (CICS). They got the highest priority and response times were great. Any spare capacity was devoted to batch jobs. This could be batch jobs that the business needed or it could be the developers submitting compilation jobs for code they were developing. The point is that it managed this mix of workloads beautifully, it ensured that the interrupt end user driven transactions got the priority and it soaked up any spare capacity with batch jobs that could be swapped in and out at will. Which brings me to the cloud.
There are many reasons that folks are advocating the cloud, but the most important would seem to be cost savings. The case is made in detail in this Booz Allen Hamilton paper which has this eye popping assumption that all the cost savings in their model are based on “Our analysis assumes an average utilization rate of 12 percent of available CPU capacity in the status quo environment and 60 percent in the virtualized cloud scenarios“. I’ve done a bit of digging and those two numbers seem to represent reality which is mind blowing to me on both fronts. The average server utilization in data centers today is a meager 12%, which is crap and means that a bunch of servers are sitting there with apps that hardly anyone uses or apps that are seasonal and so most of the time aren’t hit. It also is surprising that they only assume 60% utilization in the virtualized cloud environment. Given that the mainframe could crank at 100% all day why isn’t that number higher?
I am speculating now, but I assume it isn’t higher because they are factoring in a significant overhead to hardware-assisted virtualization (like the kind that powers ec2). The very same overhead that caused hardware-assisted virtualization to get eclipsed, in the late 1970s, by computers that could do much more efficient time sharing and hence save a tonne of money. The key questions for anyone investing in building cloud infrastructures is whether economic factors will again render this technology obsolete and whether there is something that has similar characteristics but without all the overhead? Something that say could run 1000 linux instances on a single host? It’s not even the only game in town.
Werner Vogels: Today we launched a new option for acquiring Amazon EC2 Spot Instances Using this option, customers bid any price they like on unused Amazon EC2 capacity and run those instances for as long their bid exceeds the current “Spot Price.” Spot Instances are ideal for tasks that can be flexible as to when they start and stop.
Spot Instances are ideal for Amazon EC2 customers who have workloads that are flexible as to when its tasks are run. These can be incidental tasks, such as the analysis of a particular dataset, or tasks where the amount of work to be done is almost never finished, such as media conversion from a Hollywood’s studio’s movie vault, or web crawling for a search indexing company.
There’s a whole class of applications that this is a game changer for. It will be interesting to follow its adoption.
Matt Heaton: ‘While virtualization techniques have improved dramatically in the last
10 years (Think 3D support, para-virtualization for direct access to
the hardware layer, etc) there is a fundamental problem with the whole
concept of virtualization that no one ever talks about.’
I don’t know why this isn’t getting more attention. You can cram a lot of shared hosts on a single box. You can get nowhere near the same number of guest operating systems using virtualization. As a data point, I am paying $6.95 per month for shared hosting, I am running 4 domains and countless applications. To keep this blog running continually on amazon elastic cloud would be $70 per month and a lot more labor.
As an aside, it is also worth noting that certain language runtimes are way better suited to shared hosting than others. Ones that support fork, shared libraries, process isolation and start fast, good. Those that start slow, rely on threads and don’t share memory not so good. hmmmmm
One of the projects that I keep an eye on is LLVM. In a nutshell it is apple’s compiler strategy but is also “an aggressive
optimizing compiler system that can be used to build traditional static compilers, link-time optimizers, run-time optimizers and JIT systems”. The guys behind it eventually want to replace gcc, and fwiw I think that they eventually will.
It seems that every language on the planet currently has someone experimenting with porting the language to llvm. This includes java and .net, ruby, python, and a very interesting use of LLVM to AOT compile flash so it can run on the iPhone.
The LLVM folks recently had their 2009 conference and I just got through watching the presentation on Unladen Swallow. Unladen Swallow is an attempt to get python to go five times faster by porting it to LLVM. They also hope to be able to make it the default python compiler / JIT. They have made pretty good improvements so far, however they are running into all the problems inherent in making any dynamic language go faster, namely type inference. I’ve blogged about this before for Java and the unladen swallow presentation does a good job of explaining all the pitfalls around making a dynamic language go fast (hint, try and avoid all the indirections). So far Unladen Swallow seems to be trying to work out how to safely infer types for a host of things and it will be interesting to see how far they can get with this.
The sad state of affairs however is that none of the popular dynamic scripting languages really go very fast, they all consume a lot of CPU. I can’t help thinking that we are all effectively driving around in Hummers by using these languages. What Unladen Swallow seems to be trying to do is make a Hummer Hybrid, sure it consumes a little bit less gas than a regular Hummer but its still a Hummer and is fundamentally not designed to ’sip’ gas. We need the programming language equivalent of the Prius or a Jetta TDI i.e. something that a lot of us would be willing to develop web apps in (i.e. not C++) as well as something that is CPU friendly.
The real question then, is whether there is a language or a set of languages that can ’sip’ CPU while still feeling dynamic and programmer friendly. The closest I have found so far is boo. It’s a python inspired .net language that can run on mono. As the manifesto states the language has been explicitly defined for type inference throughout (as long as you don’t use duck typing). This should mean that most of the time it flies. At the moment this performance difference may not be that much of a big deal, but as we move more and more services to the cloud and as we consolidate to a few super cloud hosting organizations it is going to be a significant advantage to be able to operate a cloud with 10 or maybe a 100 times fewer servers than your competitors who are all hosting ‘Hummer’ like languages. Given the financial pressures and incentives it seems inevitable that we will all eventually be ditching our Hummers and discovering languages that are designed to ’sip’ cpu. These ‘hybrid’ languages will probably honor the dynamic driving preferences that most web programmers have gotten used to over the last few years while making heavy use of type inference to provide static language like efficiency. Anyone want to port django to boo? :)
Google Wave is a great leap forward in user experience. It attempts to answer the question ‘what would email look like if it was invented today’. It, however, started from a clean slate, which I am not sure we need to do. I think we need to look at the kind of collaborations now taking place on the internet and look at streamlining their user experience. Given the spread of social sites and the volume of data exchanged within them it seems to make sense to look at those for some inspiration on how to reinvent / tweak email.
A lot of the social sites allow for collaborations and provide a notifications when a collaboration within the site has taken place e.g. a status updated, or a status commented on or a photo shared. Most of them send you an email with a link. Something like this.
You click on the link, then you login and finally you get to respond, at which point more emails are sent out to other participants, who all open emails, click links and login and around and around we go. The important point here though is that the social site maintains a single copy of the collaboration and makes it available via a url. Contrast this to collaborating in email.
Email today shunts around copies of html documents for collaborations. It does this as there have been historical constraints that make this the only practical design. The big two constraints were intermittent connectivity to the internet and a lack of single sign on for the web. The last point is not immediately obvious as something email addresses. It achieves it though by sending and then storing a copy of the collaboration in a store that the recipient is authorized to view. Its advantages becomes glaringly obvious when you try and share photos privately for the first time with your mother via facebook. The set of steps required for her to sign up, choose a password, etc. quickly become too tedious and cumbersome to make this a universal approach.
Both of these design constraints are however disappearing. Netbooks from cell phone companies and recent announcements from airlines make ‘always connected’ a reality and openid and oauth momentum, which both have a role to play in web single sign on, seems unstoppable. Openid has also recently been paired nicely with oauth and has had some nice usability improvements.
In addition to these design constraints disappearing another shift makes a rethink timely.
Email as a Service – Most of us are now getting email from a web site e.g. gmail, hotmail, yahoo. As this is a service in the cloud any data that I have in the service is available for integrations, e.g. it can provide a standard api for getting at contact data which is a big deal. In addition it can provide many other services for third parties to integrate with (more on this later).
My previous post claims that we should start to think about sending something other than html to each other over SMTP. This post will walk through what sharing photos with my mother could look like if facebook sent an atom entry instead of html with a link and if gmail understood how to interpret the atom entry. The main goal will be to provide an approach that my mother can use.
Here’s a possible step by step
1. I share a facebook private photo album with my mother by just entering her email address.
2. Facebook sends an email to my mother that also contains an Atom Entry as below (note that this can be in addition to the normal text and html representations all bundled up in a mulipart message)
<entry>
<title>Rob has shared the album Sugarloaf 2009 with you</title>
<link href="http://facebook.com/photo.php?id=8237298723&mode=preview&email=mom@gmail.com&oid_provider={oid_provider}"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2009-06-13T18:30:02Z</updated>
<summary>Rob wants to share the album Sugarloaf 2009 with you.</summary>
</entry>
Note also that the link utilizes uri templates. This is needed so that facebook can be passed the user’s openid provider’s endpoint by the email service.
3. My mother (who uses gmail for her mail) logs in and sees that she has an email from facebook stating that I have shared an album with her. She opens the ‘email’. Gmail spots that the email contains an atom entry, extracts the link href, substitutes in the url for google’s openid endpoint and opens the web page within the mail client (probably in an iframe). My mom just thinks she opened an email.
4. Facebook now needs to work out who the user at the browser is. It already knows that the user at the browser is associated with the email address mom@gmail.com as it embedded this in the atom entries link url sent to her in the email (this is similar to the way that most web sites validate ownership of an email i.e. those ‘We just sent a confirmation email to you, please click the link…..‘ kind of things). Facebook now just needs to get my mom’s openid, associate it with her email and my mom can then automagically become a facebook user with an account that has access to the shared photos. So.
5. Facebook redirects to mom’s openid provider (which is google) and which was provided to facebook in the url. It does this from inside the iframe, so as far as my mom is concerned this is all taking place inside her email service. The redirect probably uses html fragments so that the context is not lost and it is implemented very much like the openid ui extension except it is both the RP and OP that use fragments. This redirect causes gmail to pop up a box that asks my mom’s permission to share her name and email with facebook.
6. My Mom grants permission causing a redirect back to facebook (in the iframe) passing back to facebook her openid, name and email. Facebook now sets up a new account for my mom associating my mom’s google openid with her email mom@gmail.com. Again as far as my mom is concerned all this is taking place within the email service. She has never left her inbox.
7. Mom now sees the message open and sees my photos rendered live from facebook in the message pane. If there has been any updates to the photos or comments she sees all of them. Mom can now also post comments on the photos in the iframe rendered right inside gmail, before moving onto her next message.
If I now share subsequent photos with her via facebook then the same dance occurs when my mom opens the message, but this time google no longer needs to ask for my mom’s permission to send along her openid so as far as she is concerned the photos delivered straight from facebook open up right inside her email client.
There are probably many services that would benefit from this kind of email integration. Facebook, flickr, evite and google groups spring to mind as does my current defect tracking system which I am sick of logging into :)
There are lots more variations on this theme. The atom entry can contain mulitple links, one could be for preview, one could be for full screen, the links could even represent REST services that would allow programatic access to the data from the email service. In addition the modified timestamp along with the id field in the atom entry can be used by the mail server to ensure that you only see the latest update and don’t have to wade through 12 emails of updates for the same thing. As a final thought a gadget xml could be sent in atom entry content section. There are a realm of possibilities, but it all begs the question, why are we still sending each other html?
Don’t get me wrong I think that it is a great user experience and a great leap in invention (putting aside concerns that I have about attention management) but I don’t understand why it was built the way it was built. Sure it allowed them to do that neat search trick, but frankly, who really needs that.
At some basic level wave is about getting notifications that a shared collaborative space has changed. The shared space is held somewhere in the cloud and has a set of capabilities. There are a set of capabilities that wave collaborative spaces have (live real time editing et al) and those were cool but quite frankly, who cares?. The shared collaborative space should be just a web page, any old web page and so it can do whatever a web page can do. It can do real time group chat or code editing or realtime document editing, but why should it be constrained to being some XMPP Wave thingy. You get a message in your inbox, you click on the message and go to a shared space in the cloud and in that space stuff happens. Maybe the space uses the wave protocol but maybe it doesn’t and it shouldn’t matter. It’s just a url.
So what would be needed if, instead of building wave the way it was built, we simply built an inbox that alerted the user when web resources of interest to them had changed and that launched web pages (in the context of the inbox) when messages were opened? I think it is a short list of standards and great progress is being made on all of them.
Single Sign On – A lot of the notifications in the inbox would probably be about data shared privately with a group of individuals, as such authentication will be needed before viewing the data. It would be a terrible user experience if every message that you received required a different login to a different site to view the pages. However, more and more sites are now standardizing on openid. If openid is widely adopted, and it is quickly becoming the only game in town then this barrier comes down and it becomes possible to launch urls that represent private collaborative spaces without the need to continually login. As an aside, the inbox may need to pass along the openid identity provider for the user to the site, but that is very doable.
Portable Contacts – The other thing that is needed is the user’s contacts to follow them around the web. The user should have their collaborators available to them on any collaborative space (i.e. url) they visit so that they can easily bring them into the collaboration. The opensocial rest api already provides ‘portable contacts’ so collaborative spaces can provide type ahead etc. against the user’s contact list when sharing with other collaborators.
Notification - The final piece of the puzzle is how changes to the collaborative space make their way to a user’s inbox. Given the inbox metaphor SMTP seems like the natural choice. However, traditional approaches to sending an email update when a web based collaborative space changes involve the user, opening the message, clicking on the url link in the message and then logging in, not pretty. Google Wave excelled here, opening the message opens the collaborative space immediately, no login, nothing. What if the SMTP message shipped the data in a format that describes the update and contains a link to the collaborative space. An inbox client that understood this data format would display the meta data in the message list and launch the site immediately when the user opened or even previewed the message. So we are looking for an existing standard that provides meta data about a url. Atom, seems like the most natural choice. So notifications can be sent to the user by sending atom entries over SMTP. As an aside the multipart message sent to the inbox could also contain text and html representations that contain a url link for compatibility with inboxes that cannot process atom entries.
Does this work, would this provide the main features of Wave or have I missed something fundamentally different about Wave? I really like the user experience of Wave but I don’t understand why it needs XMPP et al. What am I not seeing?
The database should always be the bottleneck in any large scale web application. As such, it is becoming increasingly important to minimize concurrency and to eek out every last bit of performance from the database.
There are a set of techniques for improving concurrency in sql code. The one I have personally seen most widely applicable is best seen with an inventory example. Suppose that you are buying 10 copies of Jim’s book from Amazon. The logic starts out with a predicate i.e. does the store have 10 copies of Jim’s book in stock. If it does then reduce the quantity by 10. Pseudo code would be as follows.
Select quantity_on_hand from Inventory where ISBN = 'IUWHSUY' FOR UPDATE;
If quantity_on_hand >= 10
Update Inventory set quantity_on_hand = quantity_on_hand - 10 where ISBN = 'IUWHSUY';
While this is pretty efficient it can be improved upon by combining the predicate i.e. ‘if quantity_on_hand >= 10′ with the transform i.e. ’set quantity_on_hand = quantity_on_hand – 10′ into a single SQL statement.
The resulting single sql statement is as follows
Update Inventory set quantity_on_hand = quantity_on_hand - 10 where quantity_on_hand >= 10
The application then checks the return of the update call to see how many rows were effected. If it was 1 then all is well (there was enough stock and the inventory level has been reduced), if it is zero then there aren’t enough items in stock.
This pattern comes up over and over again and the single sql statement is ALWAYS preferable to sending off two separate sql requests i.e. one that checks whether some condition is satisfied and then another to perform the update.
Update:Removed reference to ‘field calls’ which was pointed out to me actually refers to pushing this support further into the db manager, the above pattern still holds though, just not called a field call