Google staff engineer Adam de Boor gave a keynote this morning at Usenix WebApps '10 in Boston, where he outlined a few of Gmail's next steps. The webmail application, which launched in 2004, has aggressively added new features in the years since, and is currently launching as much as one new feature a week.

De Boor said that there's currently a big push at Gmail to figure out how to take maximum advantage of HTML 5, a standard Web technology that's been increasingly adopted by browser vendors. HTML 5 allows web applications to behave more like desktop applications, and Gmail recently started allowing users to attach files by dragging them into the browser window.

In the future, the company hopes to extend that by allowing users to download files by dragging them out of the window. By improving its applications this way (and by making complementary improvements to its Chrome browser), Google plans to show that Web applications truly can do everything desktop applications can do.

The company also plans to use HTML 5 to pursue its obsession with speed. In particular, Google's experiments with HTML 5 and the associated CSS 3 show that using those technologies could speed up Gmail's load time by 12 percent.

The company has also been researching a new model for Web applications that could speed up load times even more. In experimental builds of its Chrome browser, Google has started allowing users to install Web applications, meaning that the browser keeps a page for that application always loaded in the background. This means that the Web application always has up-to-date data, and is always just a click away. When the user types the URL for the application, the browser links the user to that preloaded background page, speeding up the time it takes to get to the service.

By applying this technique to Gmail, De Boor, said, the hope is to get the webmail application to load in under a second. Google's vision for the speed and behavior of Gmail is likely to set a standard for Web applications across the board.

Numbers on Facebook's exponential growth often get thrown around, but it can be hard to comprehend what those numbers mean. The site is becoming the repository for huge quantities of information about the daily lives of its users, and it can be easier to understand how significant this is when listening to company executives discuss how Facebook struggles to manage all of this information. Bobby Johnson, director of engineering at Facebook, spoke this morning at the Usenix WebApps '10 conference in Boston, where he outlined how the company handles the technical and organizational problems created by its rapid rise.

The site's 400 million users have an average of 130 friends each, and just this social graph data is tens of terabytes in size. What's more, this data has to stay accessible at all times, since it's used to respond to almost any action that a user takes. For example, when a user logs in, data about that person's social connections is used to figure out what information to display in the user's news feed (the first screen shown after login).

On top of keeping track of users' connections to each other, Facebook has increasingly become the archive for users' personal memories. The site has long been the largest photo-sharing site on the Web, and virtual photo albums have in many cases replaced the paper albums that used to sit on people's shelves.

But while the accumulation of photos and videos may become an issue for the site in the long run, Johnson says that for now the main issue is dealing with new data. More than half of the data currently on the site was added this year, he says. Facebook plans never to delete old data, but even if they did, Johnson notes that it would do little to relieve the challenge of storing the flood of new data.

The company obviously takes the responsibility of storing all this data seriously--it routinely replicates information at least three times to ensure it is safe from hardware failure and bugs. It's stunning, however, to contemplate how large a responsibility the company has for information belonging to a growing number of people around the world.

Here at South By Southwest Interactive, the keynote interview of Daniel Ek, the 26-year-old founder of European music service Spotify, provided some satisfying insight into the major new music site.

Spotify has built a lovely music application that uses a peer-to-peer architecture to stream music at lightning speeds (a real improvement over the sometimes spotty service that comes with many other music streaming applications). The site is only licensed in Europe, but Ek says the site has 7 million users in 6 countries, and he's been working hard to get it licensed in the United States. Users can listen to music for free, with ads, or can pay for a subscription that grants access to perks such as the Spotify mobile app, and song downloads.

I couldn't help noticing, however, Ek's artful dodge to the question of how artists are paid by his service. The subject was broached by an audience member, who identified himself as an independent musician and thanked Ek profusely for the great application. He wanted to know how much he would be paid.

"It's complicated," was, in essence, Ek's reply. But he did reveal that it's a revenue sharing model; artists get paid a proportion of whatever Spotify gets paid, presumably based on the number of plays on the site they receive.

Ek's reply was disappointing because this is the million dollar question for many music sites. Pandora's been on the verge of going under for years in part because they've paid artists even when they couldn't afford to. It's clever of Spotify to find a way to be cash-positive where other sites have failed, but it means the artists must wait to be paid a fair rate.

There see other problems too. For example, pop stars are likely to draw the highest proportion of plays, but how does that relate to which fans pay a subscription fee? It seems that part of what Spotify will need to figure out is what brings money to the site and how to reimburse artists fairly.