Using ReadWriteWeb as an example, he goes into great detail about how speeding up PHP isn't simply a matter of finding a single magic bullet. Lerdorf contends that true optimization comes down to attacking the mundane inefficiencies that sneak into sites of all sizes - even suggesting free tools for PHP devs to use - before a solution such as HipHop is considered.

But first, for an overview of what HipHop is (Facebook's rewrite of the PHP runtime) and what it does (translates PHP to C++ and compiles it with g++), check out our growing archive of HipHop posts or watch this video from Facebook:

Lerdorf begins his assessment of the project on a positive note. "I think it is a cool project and it will certainly be a good option for some sites," he wrote to us in an email.

"The effectiveness is going to depend a lot on the type of code it is used on. Like similar projects such as Psyco, Cython, Pypy and ShedSkin in the Python world, results vary greatly."

However, he continued to say that raw execution speed was "not a significant factor" for many applications. "Even if you double the execution speed of something that is 10% of your overall request cost, that is only a 5% overall improvement. If on every request you are hitting memcache/postgresql/mysql 10 times and spending a lot of time in system calls, don't expect miracles from HipHop."

Calling the code translator "a nifty trick," Lerdorf worries that some developers will see HipHop as "some kind of magic bullet" for site performance. Noting the amount of hype he's seen lately about the new runtime, Lerdorf wrote, "I'd love to see those same people get excited about basic profiling and identifying the most costly areas of an application. Speeding up one of the faster parts of your system isn't going to give you anywhere near as much of a benefit as speeding up, or eliminating, one of the slower parts of your overall system.

"People generally don't bother doing even the most basic site optimizations. PHP execution speed is usually quite far down the list if you sit down and profile the end-to-end series of HTTP requests that lead to the final page in a broswer..." At that point, Lerdorf was kind enough to give us a run-down of site issues with ReadWriteWeb.com that we dutifully passed on to our new and often beleaguered webmaster.

"These are relatively minor and very common things, but they all contribute to your users' perceived performance of your site. And that's just the frontend. If I sat down with a profiler and looked at your backend I predict I would find similar inefficiencies."

In a word, Lerdorf is telling us all to not get too excited about the "nifty trick" that is HipHop until the runtime is the biggest thing that's stopping a site from being as fast as possible. Given Facebook's engineering focus, we can imagine that the site's been pretty well optimized and HipHop gives enough efficiency to give users a faster front end while also using fewer server resources.

Lerdorf ended by suggesting Yahoo's YSlow and Google's Page Speed for analyzing front-end issues, and he recommended Valgrind's Callgrind for low-level back-end profiling and XDebug for userspace PHP profiling.

If that sentence confused you, then you're not the target audience for this post. We want to know what our developer friends think of HipHop, the latest open-source code project to emerge from the deep, dark dungeons of Facebook's Palo Alto headquarters (ok, the HQ's actually quite pretty, but we like a good turn of phrase). Read these expert opinions (and by "expert," we mean Rasmus Lerdorf), and let us know in the comments what you think of the new PHP runtime.

Facebook engineer David Recordon told us this morning, "HipHop isn't actually a just-in-time compiler. Rather it transforms your PHP source code into C++ and uses a well established compiler (g++) to produce the resulting binary."

The Facebook engineer who was responsible for concepting and developing HipHop, Haiping Zhao, wrote this morning, "With HipHop we've reduced the CPU usage on our Web servers on average by about fifty percent, depending on the page."

So, with HipHop, Facebook (and by extension other PHP-based sites and apps) becomes faster and more scalable, since rewriting the runtime probably cost a lot less than trying to scale horizontally with more servers.

Late last night, we pinged PHP creator Rasmus Lerdorf on Twitter, asking for his opinions on the new PHP runtime. This morning, he wrote, "I think HipHop is cool and will certainly help the poor people stuck in framework soup." However, he also noted, "HipHop on simpler template-style PHP pages probably isn't going to help you too much. It's not going to make your SQL queries any faster."

Our friend and a PHP dev himself, Warren Benedetto, wrote to us with a wealth of interesting implications, saying, "[Facebook] get to have their cake and eat it, too. Keep the site in PHP, keep their large staff of PHP developers, rapidly iterate existing features while developing new ones, AND get all the performance benefits of a compiled language on the back end."

He also notes that the improved speed and performance might cause more enterprises to consider using PHP for sites, features and applications rather than Java or .NET.

But one of our biggest concerns with HipHop was the delay in open-sourcing the project. Former Digg lead architect and current SimpleGeo co-founder Joe Stump wrote this morning on Twitter, "Thanks, Facebook, for open sourcing HipHop. We, the FOSS [free and open-source] community, look forward to maintaining this fork separately from you going forward." Take that!

So, that's what a few of our friends and acquaintances think of Facebook's HipHop and the rewritten PHP runtime. What's your take on it? Let us know in the comments!

Acer, currently the world's second-largest computer vendor, mentioned the application store among a series of initiatives designed to boost the company's profitability, according to a report on Bloomberg.com. From what it sounds like, Acer is glomming onto every major tech trend with plans that include everything from an e-reader to a Tablet PC. In fact, Acer chairman J.T. Want even admits this is the case: "We'd like to proactively purse any opportunity," he said.

One of those opportunities is the new Acer application store, an online venture that will offer hundreds of different applications, both free and paid. However, the company wouldn't share pricing details or name developers, noted the Bloomberg story.

Although application stores are typically associated with mobile phones, Acer wouldn't be the first vendor to launch an applications store designed for use on PCs. Earlier this month, chip maker Intel launched the AppUp site, an application store designed specifically for netbook computers. Interestingly enough, AppUp is meant to be a white-label offering that PC manufacturers can customize to their own needs. At the time of its launch at this year's Consumer Electronics Show in Las Vegas, Intel announced several partnerships with other PC makers to bring the AppUp store to consumers. Included among those launch partners was Acer. Gianpiero Morbello, Acer's worldwide marketing VP said that by accessing the AppUp catalog, their company would be able to distribute "innovative software downloads to Acer Atom processor-based netbook customers and move to easily support additional Acer customers on any device powered by an Intel processor."

So Is This Yet Another App Store?

However, despite the sparse details surrounding the upcoming Acer app store, it does sound like the manufacturer is planning their own venture of sorts. Intel's store only supports Windows netbooks and the Moblin Linux operating system - not mobile devices like Windows Mobile or Google Android and definitely not Google's new netbook OS, Google Chrome.

Intel confirms that the previously announced joint venture is still on, with their company providing behind-the-scenes support for infrastructure, testing, and validation of apps. And while Intel isn't privy to Acer's other plans, it does appear that this would be a separate store from whatever Acer is envisioning for the other platforms outside of Atom-based netbooks.

It's understandable that Acer wants to generate some hype surrounding their products by offering an app store to their customers, but at this point they may be simply confusing the issue. Many of the platforms Acer plans to support already offer their own application stores - even Google's Chrome OS, the Web-based operating system set to launch by year-end. And, of course, one could argue that the Internet itself has been the app store for Windows computers for many years now.

Of all the applications outside the browser, server-side Javascript is the most alluring for reasons described in this post. An idea that would have had you laughed out of the room a few years ago is edging towards reality.

This guest post was written by Michael Mahemoff, who works at Osmosoft as lead web developer and blogs regularly for Ajaxian and on his his personal blog, Software As She's Developed. You can follow him on Twitter.

The Perfect Storm

Server-side Javascript isn't a new phenomenon; Netscape stuck Javascript in the server way back in 1996, right after they introduced it to the world as a browser technology. Interest soon waned, and the language was confined to the browser for the most part. Even there, it didn't get a whole lot of respect and was frequently dismissed as a hack language capable of no more than annoying alert boxes and gratuitous ticker tape animations.

But suddenly, serious web-based applications started sprouting up. GMail, Google Maps, and JotSpot (kind of a Google Docs predecessor) were all running inside the browser. They weren't supported by Flash, nor ActiveX, but Javascript manipulating the browser's Document Object Model (DOM). The term "Ajax" was coined to describe these applications, and a community flourished. A few years on, Javascript has become the world's most popular programming language by some accounts. Not so surprising when you consider its special status as the standard language shipped with all major browsers. It's the web's lingua franca. While most web developers have a favourite, primary, language for server-side work, they converge on Javascript when it comes to the browser. Javascript today can be compared to the English language: it's arguably the most popular language as long as you count basic competency, not just outright fluency.

Given that you're already using it in the browser, why not stick it in the server too? One language all the way down makes it easier for a single programmer to work on either side of the wire; there's less of a mental shift. For project managers, the trend would make it easier to move developer resources between the front end and the back end if a common language is used on both. Many in the developer community now recognize Javascript as a respectable language, with understood patterns for effective use. In fact, many of Javascript's negatives were a case of misdiagnosis: the problem was really the browsers' DOM (Document Object Model) APIs, not the language itself. Take those out of the equation and you're left with a solid language capable of tackling diverse problems.

There's also a promising reuse story for this "dual-side Javascript" scenario. Take form validation for example. Right now, it's common to write the same logic in two different languages. In Javascript, you write a validator to give the user immediate feedback inside the browser, and in a language like PHP, you write a validator to ensure data integrity once the form data has been uploaded to the server. But once you switch to Javascript on the server, you just need to write a single validation routine at both ends. Under some styles of development, you can also arrange for a function in the browser to directly call another function inside the server; the code is smaller and simpler to write, not being bogged down in the technical details of transferring data across the network.

Javascript performance has also moved forward in leaps and bounds, thanks to browser competition. Firefox's Javascript engine, Spidermonkey, increased in speed by a factor of 20-40x. Safari's underlying engine - Squirrelfish, aka Nitro - posted similarly impressive gains (see chart below), and Google Chrome came on the scene last year along with its highly optimized V8 Javascript engine, a very real contender in the "fastest Javasript engine" stakes.

Server-side Javascript also dovetails nicely the new breed of NOSQL databases. Being web-native, these databases tend to communicate in HTTP, and in some cases JSON (JavaScript Object Notation) is the message format. Javascript libraries already include support for exactly that kind of interaction and programmers are familiar with them. Some of these NOSQL systems go beyond data persistence and into the zone of full-fledged Javascript application environments.

Towards A Mature Server-Side Ecology

In the simplest case, all you need to run server-side Javascript is a Javascript engine to plug a web server into. There are plenty of open source options here; the choice will come down to the language its implemented in, which affects the kind of environments it can run in, in addition to the usual factors like performance and level of support. Many Javascript platforms run on the Rhino engine for example, and Rhino is built in Java; this means that they can easily integrate with Java components. Thus, you can build the entire user-interface in Javascript - including a thin UI layer on the server - and still have it backed by a conventional enterprise Java stack. Helma is one prominent example of this architecture.

Once equipped with a Javascript engine, you can write simple CGI scripts as you would with any other language - read the request, write the response. In practice, you'll also want good library support to get anything useful done. Some environments do come with libraries, and you can also make use of existing libraries developed for browser-based Javascript. What will really make the biggest impact, though, is industry-wide standardisation. To that end, there's a strong grassroots movement underway to converge on a complete API: CommonJS is defining an API for file access, networking, unit testing, and so on, as well as declaring how these components should be packaged for easy import. Multiple efforts are implementing the nascent spec in several major Javascript engines (Rhino, Spidermonkey, V8, EjScript). One open-source platform complying with CommonJS is Narwhal. It has considerable momentum and runs on several of the Javascript engines.

CommonJS is raising the level of abstraction for server-side Javascript and allowing developers to use patterns familiar from high-level servers in other environments. Writing a web server no longer means hand-coding the lower-level cruft. Thus, you get a framework like Jack, which is similar to Python's WSGI and Ruby's Rack. Jack's based on the idea of fine-grained "middleware" libraries, able to be composed and reused, and there's a separate project, Nitro, to build such components for Jack. So Nitro builds on Jack, and Jack builds on CommonJS. This is an example of the ecosystem beginning to emerge in server-side Javascript.

Use the Force! Building on Javascript's Strengths

In the previous section, I treated Javascript as just another language with all the usual server-side abstractions and the well-trodden path towards modularity and reuse. That's not a bad thing at all, since we also benefit from the synergies of running the same language in the browser and the server mentioned earlier. Where things get really interesting, though, is with frameworks that exploit Javascript's unique characteristics.

It's easy to get carried away with Javascript's efficacy as a regular scripting language, so let's remind ourselves that its roots are inside the browser. What the browser has, that a generic web framework doesn't, is the Document Object Model (DOM). This is the browser's model of the web page's contents. What if we gave Javascript access to a DOM?

DOM access is a key feature of the Jaxer environment. It gives scripts access to an entire server-side Firefox instance. Developers can therefore manipulate content as they would in a client-side application, and output the resulting page. This overcomes one of the objections with Ajax apps, which is "what if the user has turned off Javascript?". The page still comes out as plain old HTML. That's a lot of power, and the patterns for using this kind of thing are not yet fully understood, but it has plenty of potential for exploration. There are also potentially great benefits for testing client-side applications if you can simulate an entire browser instance. jQuery founder has been working on a product called env.js. Where Jaxer is essentially an entire Firefox instance, env.js is an attempt to build a simulation of the browser environment from scratch, under active development. It's too early to say if its scope will stretch beyond testing and into the realm of server-side Javascript.

DOM manipulation may be one characteristic thing about Javascript we can exploit, but there is also another (related) thing: event-handling. The language was more or less designed to respond to user events, so it has a great model for handling them that is familiar to any Javascript programmer worth their salt.

For most server-side programmers, event-handling capability will yield a big fat "who gives a damn?". Server-side scripts don't sit around waiting for events to come in. They usually just look at an incoming request, deal with it, and send out a response. Then they exit as soon as they can. All good stuff, but there's a completely different paradigm possible. It's part of the trend towards the real-time web and the design pattern known as Comet.

With Comet, the server holds on to the connection for a while, and continues to stream out information intermittently to the browser. The typical example is a two-way chat - as soon as one guy says something, the Comet server sends the message to the other guy. This is event-driven programming all over again, and compared to the usual suspects on the server, Javascript is well-placed to support this paradigm.

A framework that's taking advantage of all this is node.js, or just "Node" to its friends. Node is interesting because it requires scripts to explicitly close the connection; if they don't close it, the connection just stays open and the script can handle events as they come in, usually by sending more information down to the browser. Less than a year old, the project already has a strong community and numerous derivative frameworks and applications. A similar model has been used in other frameworks, like Python's twisted, but Javascript may turn out to offer a neater syntax for this kind of thing. By daring to be different and using javascript for what it's best at, Node is shaping up as a framework to watch. The speed of Node apps is likely to give Javascript serious cred among server-side developers.

The Cloud. Of Course, the Cloud!

No article on server trends could ignore the famous cloud. How does javascript work in virtualised computing environments? With a suitable engine, you can certainly set up an environment manually using amazon EC2, google app engine, or similar cloud hosts. However, you can do it easier than that with some of the other solutions around. Joyent took a big bet on Javascript when it acquired Reasonably Smart earlier this year; the host now offers a dead-simple runway to host Javascript scaleably. Aptana, the company behind the Jaxer platform described above, does likewise.

Something's Going on Here

Before we get too excited about this trend, I should make one thing clear. Conspicuous by their absence are the real-world server-side Javascript apps. There don't appear to be many sites running Javascript in the server at this time. Probably the most popular site powered by Javascript is EtherPad, the real-time collaborative notepad from AppJet, the company acquired by Google last week. This is a cautionary example, because AppJet launched as a cloud-based server-side Javascript framework before dropping it to concentrate on Etherpad. Aptana has also announced they are pulling back on Jaxer due to difficulties monetising it. Maybe this is more of a statement about cloud hosting revenue models than server-side Javascript, but it's worth asking how other attempts to propagate server-side Javascript will fare.

One of the critical success factors will be a comprehensive standard API; it's a prerequisite to a vibrant ecosystem of interoperable components, and with a range of engines to run on. We now have the seeds of that with commonJS. Another factor is best practices for using the language; again, we've already discovered much of that as a side benefit of the Ajax revolution. Frameworks like Node, which build on Javascript's unique characteristics, are building on those to establish best practices for server-side Javascript. Reuse of both knowledge and practices will give Javascript its best chance yet to stand up as a viable alternative to the usual server-side suspects.

Although Javascript is a far better language than was previously assumed, its syntax still has plenty of quirks. If we restrict ourselves to the subset of Javascript found in all the major browsers today - and arguably it makes sense to do so - it's arguably lacking certain features of other server-side languages. Those other languages are free to evolve autonomously; in contrast, Javascript's fate is heavily determined by standards bodies, browser manufacturers, and the patterns around how users upgrade their browser.

In this sense, the language's strength - shipping with every browser - is also an Achilles' Heel. That said, the language may well prove "good enough". The benefits of "one language all the way down" may outweigh the cost in many cases. The will is stronger than ever to make server-side Javascript a reality, and it's translating into a visible surge of activity in the web community. There's the promise of code reuse and the possibility of cutting in half the number of programming languages involved in building a typical web application.

Many smart developers have gravitated towards Javascript in recent years, as a means of producing world-class front-end apps. The attention has progressed our understanding of the language. Should server-side Javascript go mainstream, a third wave of Javascript developers will be joining the community and enriching the ecosystem.

A complete list of APIs include:
1. Real-Time Stream API:This API gives developers real-time push capabilities. Developers can control data flow through a series of granular filters. In addition to Google, the company's first API partners include Groovy Corp and One Riot.
2. Status and Mood Commenting API: This tools allows developers to integrate MySpace mood and status updates to 3rd party sites. From there users can comment on the 3rd party site with real-time syncing to MySpace.
3. Open Search API: This allows 3rd party sites to include MySpace profiles in search results. While other services allow users to search for people by location, the unique aspect of this is that you can filter by words like "celebrity" and "musician".
4. Photo Upload API: This allows users to upload photos to MySpace from 3rd party sites.

In addition to the API tools, the company has improved it's post-to/share tools. Users can now post content from 3rd party sites and stream it directly to their MySpace activity stream with a link back to the original content.

To encourage creative use of the APIs, MySpace is also launching a developer's challenge. For info, developers can visit the MySpace developer's wiki.

The IPTV integration is an interesting one and Philips doesn't seem like an obvious partner. What other types of partnerships do you have in store for us?
Honestly, we're not only looking to partner with the big brands, PayPal also wants to enable innovation from the little guy. We know we'll reach success when developers exceed our expectations. We're looking to them to decide how it plays out. Without taking credit for other developers' work, there are some great areas to innovate in voice authorization, real-time mobile applications, shipping, consumer apps and coupons.

What does the future of PayPal look like?
We're launching an app store where consumers can check out new and convenient payment forms and merchants can purchase specific solutions.

How is this connected to Le Web's theme of the real-time web?
We're looking to provide real time payment options and support.

As a global leader you've got every opportunity to dictate industry pricing on apps and merchant services. What is the percentage you're going to take off merchant purchases from the app store?"
We're not sure of that yet. What we do know is that it's going to be fair. We don't want to take our cue from some of the other closed platforms. We're offering visibility, easy integration of payment and smooth transactions. We're not trying to be Apple, we want as much cross device, cross platform transactions as possible. We make our money off the transactions, not the applications.

If the future of PayPal is about seamless app integration, then doesn't that mean that in a perfect world PayPal is virtually indistinguishable from the app?
Not exactly. We offer developers security authorization. Consumers want to know that their money is safe. There are lots of other providers, but developers choose us because our brand offers a sense of security. We're leveraging the success of our payment brand and the developers are responding.

For more info on Le Web, check out Social Media Club House

According to the site's About page, Martin writes that "it's now gone from 'easy' to 'tricky' to avoid getting your app rejected by Apple." And since Apple has refused to document or discuss the matter of application rejections, he was inspired to create this website as a place to collect all the known application rejections.

The App Rejections site itself is in the format of a basic blog. There aren't catchy headlines, images, or accompanying snarky commentary in the individual posts as you would find elsewhere in the tech blogosphere - especially on TechCrunch where documenting high-profile app rejections has become somewhat of a pet project of blogger MJ Siegler. At the most, Adam may inject a few opinions of his own as to how certain things could be improved, but he clearly isn't on any sort of vendetta against the company.

Instead, each post details point-blank exactly why a particular application was rejected, examining information about the APIs used or rules broken in each case. The site also documents when formerly rejected apps finally make it through to the App Store in posts titled "approved" or "overturned," the latter referring to apps whose developers started some sort of appeal process.

Although the site is brand-new, with only two pages of posts so far, it could easily become an invaluable resource for iPhone developers confused by Apple's murky review process which can sometimes lead to apps sitting in limbo for months on end before any word from Apple is had.

Developers looking to have their personal experience documented on the site are advised to contact Martin via his company's Twitter account, @redglassesapps.

With all the news from the event, one thing was clear: RIM desperately wants developers to build for Blackberry and is now actively enticing them with a slew of new offerings designed to win them over.

One of the biggest announcements made yesterday involved the launch of new APIs (application programming interfaces) for third-party developers. The APIs offered include a new advertising service, a payments service, location services, and the general availability of Blackberry's own Push service, which had never before been made available to outside developers. What this means is that developers now have the tools to build applications that rival those already available on many other smartphones today, most notably, the iPhone. In some cases, the Blackberry APIs even offer something the iPhone doesn't such as is the case with the payments service which allows you to pay for apps on your next mobile phone bill.

The location services include a geo-location API that will use cell tower triangulation as a backup for when GPS fails, making location-based applications more reliable. There are also services for determining your phone's location on a map and another that helps estimate travel time for driving directions. It's obvious to see how these types of services could help build new and useful mobile applications for the Blackberry.

Also revealed was the new Blackberry Advertising Service, an offering designed to help developers generate revenue from their mobile applications. Through partnerships with ad networks, developers can easily integrate mobile advertising within their apps and track the ad's effectiveness with an included analytics package. It's even possible for these ads to access the phone's core features. For example, you'll be able to initiate a phone call from an ad or add a calendar entry from an ad. That's an innovation that many other mobile handhelds are not yet offering. These types of interactions should have a clear appeal to the many business-minded corporate Blackberry users who are often more interested in getting things done than they are with playing mindless games.

That being said, the game-playing crowd isn't being ignored either. Also announced was support for OpenGL ES, a graphics API for 3D games. While this doesn't quite put the Blackberry on par with what's available for iPhone, it's a move that's designed to keep Blackberry at least somewhat competitive in the field of mobile gaming.

Other announcements included new support for mobile developers looking to build applications with the languages and tools they already know and use. Java developers will get a new GUI builder that lets them create mobile interfaces using a WYSIWYG (what-you-see-is-what-you-get) editor with drag-and-drop capabilities. Adobe developers will be able to use the company's Flash Platform technology and Adobe Creative Suite tools to build rich, mobile apps as well. This is another area where Apple falls short - Flash still doesn't work on the iPhone. Instead Flash developers have to use special Adobe software to convert apps written in Flash to a format that's iPhone-compatible. Also, designers can now use Adobe Photoshop and Dreamweaver to build both themes and widgets using the new Blackberry Theme Studio 5.0.

Apps, Apps, Apps!

In addition to the RIM-specific announcements, a number of companies also used the Developer Conference as the launching pad for new Blackberry applications and related announcements.

Ebay, for example, unveiled a brand-new mobile app that lets you search for items, view descriptions and photos, bid, watch items, and more. It will also tap into Blackberry's now open Push services API to deliver real-time alerts as to when you're outbid on an auction. Considering that the company has already generated $400 million this year using eBay's iPhone application, this new Blackberry app should be a big hit among mobile users when it launches next month.

The popular location-based social networking service called Loopt also revealed a major update for Blackberry which includes something the iPhone can't offer due to the nature of the device: it runs in the background to continually update your location in real-time. This is one of the iPhone's biggest flaws according to critics, since so many mobile applications take advantage of always-on connectivity to track your location for the benefit of specific mobile apps. In Loopt's case, the app knows where you are in order to show you nearby friends and local businesses which you can rate. It even offers mobile coupons for the retailers and restaurants in your vicinity.

Finally, Xobni, the Outlook email search plugin that discovers social connections in your inbox, revealed their new Blackberry application, too. As with the desktop software, Xobni for Blackberry will let you find contacts in your address book quickly using Xobni Rank technology which returns results ranked based on frequency and freshness of your communication. The application will be made available sometime early next year.

The Blackberry Developer Conference continues until Thursday, so stay tuned for even more news over the coming days.

Why is Google doing this? Because the more powerful web applications become, the more important Google's search, browser and nascent OS become. More relevant to developers than some grand anti-Microsoft conspiracy, though, is that some serious UI sweetness may be forthcoming.

The Closure Compiler will scrunch up your weighty javascript for super-efficient deployment, allowing you to do more in the user's browser with a much smaller code payload to deliver. The compiler is available in binary, as a web app and as an API. Google is also releasing a Firebug extension called Closure Inspector that will translate those compiled bits of code back into their original format.

The Closure Library is a collection of cross-browser, modular, "industrial strength" UI components from across the various Google properties. Rich text editor, DOM inspector, drag and drop ala Google Maps - you want it, you got it.

Also released are a number of high-efficiency Closure Templates.

Google's Amit Agarwal says that all of the above were originally built as "20% time" projects but then became fundamental parts of some of the most popular Google applications. Now these technologies can be used in building your apps, as well.

It will be interesting to see how these Google offerings stack up and get adopted compared to Yahoo's YUI library.

Said Osama Bedier, PayPal's VP of Product Development, "We'll do 70 billion in sales this year, but there's $30 trillion dollars being spent globally. We need to tap into this... You are the X factor."

Developers can access X.com's SDKs, technical docs and API support tools to produce integrated checkout solutions. Examples of some pre-existing products using the new Adaptive Payments API include:

• The Javastore's new drag-and-drop installation and frictionless payment system;
• Instant storefronts for Facebook via Payvment's social network shopping cart system; and
• Cut-and-paste shopping solutions embedded in mobile applications, including instant purchases via ShopSavvy's barcode-enabled comparative shopping Android application.

So far, one of the key points of this morning's proceedings has been mention of the "removal of pricing barriers." As a direct shot at Amazon, the company plans to offer what it describes as an "enhanced pricing structure," with a $0.50 flat fee per transaction. For more on today's PayPal developer event, check back here for details.

For Users: Flexible Queries

One of the most interesting aspects of this library is that it gives users a lot of flexibility when they structure their queries. Ident Engine will happily accept full URLs like http://www.twitter.com/rww or just simply 'twitter.com rww' or the Webfinger email structure ('rww@twitter.com').

Not a Developer? Try these Demos

While Ident Engine is mainly aimed at developers, the team has made a number of cool demos available on its server. The Combined Profile Demo, for example, looks at a user's profiles on multiple services and then builds an aggregate profile for the user, based on commonalities it finds in these profiles. The Lifestream demo goes a step further and discovers a user's profiles on a variety of services and pulls in the latest updates. The project's homepage also features a number of additional demos.

Glenn Jones also recently released a Firefox plugin, Identify (our review), which builds on the same premises and allows users to quickly bring up the aggregate profile of any user while looking at one of their regular social network profiles.

Sharing Flash Apps on Mobile Devices

On the mobile side, Adobe and Gigya will give users the ability to share content on a wide variety of phones, including Windows Mobile and Symbian phones. Users who want to install a sharable application on their mobile phones will simply receive an SMS message with a link to the application. The service will automatically detect the type of device and deliver the right version to the user. Developers can also give their users the ability to share iPhone versions of their applications - though obviously those have to be native iPhone applications, as the iPhone doesn't support Flash.

Developers will be able to track the success of their applications through and Adobe AIR app that will allow them to measure distribution and customer usage. In partnership with Gigya, Adobe will also give developers the ability to assure installs through paid promotions and to monetize apps through cross-promotions.

Coming Soon: Easier Integration with Social Networks

Adobe also announced that it will launch another Flash Platform Service later this year that will allow developers to easily connect Flash applications written on top of Adobe's platforms with a number of social networks such as MySpace, Facebook, and Twitter. Developers won't have to worry about the idiosyncrasies of a service's API, but will be able to write their applications on top of Adobe's social platform instead.

Much like the original premise of Ning, Social Beans simplifies the creation of community websites.  However, since it is a portable format, a Social Beans site is not locked in to a single provider. In addition to the Grou.ps platform, the 0.1 version works with MediaWiki and WordPress. A Drupal plugin is also expected for October 2009. 

At this point, Social Beans is extremely experimental and while it's an interesting concept, the group's fate lies in 2 simple questions: Is it an easy enough template for non-technical users to adopt it? And perhaps more importantly, will developers build engines to run it? Let us know your thoughts in the comments below.

One feature the team purposely left out of the editor for now is an in-page chat. Given how many users already us IM or IRC already, this wasn't a priority for the team, though this might come in a later version.

Try It

If you want to give Bespin's collaboration a quick spin, here are some instructions courtesy of Bespin developer Joe Walker:

• Sign up or login to Bespin.
• Press CTRL+J/CMD+J to open the command line.
• Type 'follow joewalker' to get someone to share files with. Joe shared a project called pubproj globally.
• Type 'project list'. You should see joewalker+pubproj in your list of projects.
  Type 'set collaborate on' to turn on shared editing.
• Open a shared file by typing 'open /joewalker+pubproj/example.txt'.
• You should then be in a collaborative editing session with the rest of the Internet.
• Click on the collaboration icon (2 people) in the top right hand corner to show you who's editing with you.

For more details about Bespin itself, have a look at our earlier coverage.

It's a major move being worked on with both the Activity Streams and Open Social communities - it could push the rest of the web, outside of Facebook, in a direction that supports radical app innovation through the creation of a level playing field of readable data. And it could make MySpace a lot better, too.

Keller told us today that MySpace is working on increasing the amount and sophistication of user activity updates on the site in a number of different ways. In case anyone is chuckling and thinking MySpace doesn't matter, we should remember that only ten sites on the web are visited more often than MySpace still today. MySpace may be on the decline, but it's still hugely important and these moves it's making could help it become even more so.

Adding "Write" Functionality

MySpaceID currently allows sites around the web to offer sign-in using MySpace account credentials. The sites can then pull in some amount of a user's data from MySpace and use it to personalize the experience they have on the new site - friends lists can be synced and taste information can be gleaned from a profile to customize recommendations, for example.

The next step will be to bring in user activities from these third-party sites and display them in your MySpace user activity feed, much like Facebook Connect allows. This gives other sites access to distribution inside MySpace. Developers of other sites will be able to offer users the option of publishing their activities on these other sites back onto their MySpace profiles and friends' activity feeds.

Here's how MySpace's plan is unlike what Facebook is doing. The updates will be marked up for the types of activities they represent with standardized microformat code, beginning with the events format hCal and soon to include the book, movie or other review format hReview. Those little bits of code that will be added could have big consequences.

Keller says the company acknowledges that this won't be a small task for third-party developers, so in the meantime she is working on automated methods of pulling user data in from other sites' Application Programming Interfaces (APIs) and marking them up automatically, with the microformat code communicating what kind of updates they are (events, reviews, etc.)

Why This is Important

This kind of data normalization creates the level playing field of information that allows new applications to be written and scale up through accessing and processing large quantities of information that have effectively been translated into the same "language." You want to build an application that processes hCal events? That will be a lot more appealing when the MySpace ecosystem of connected sites is all speaking that language.

Keller says that MySpace and the community of people working on building a common Activity Streams specification for all sites have been working closely with the Open Social community, the Google-led cross-site application platform that competes with the Facebook App platform. Keller says MySpace's new activity feed functionality will be delivered from within but extend upon the Open Social framework the company uses to connect with other sites now.

There isn't any indication yet that MySpace will make these marked-up updates available in bulk to developers for analysis; they will likely remain authenticated and limited in visibility to friends who have given approval. That would be an even bigger boost for innovation, but the promotion of the standardized data format is a huge step nonetheless.

What's In It for MySpace?

So if this has a lot of potential to be good for the web - what's in it for MySpace? Two things, primarily.

First, as Facebook grows rapidly in both user numbers and integration with sites around the web through its similar product Facebook Connect, MySpace is no longer the center of the web for millions of people. This kind of product facilitates that kind of relationship, and offering outside developers write-access to MySpace will incentivize more of them to support ongoing user-connection with MySpace. The microformatted markup makes this a lot smarter than Facebook Connect, frankly.

There is a risk that all the smarts in the world won't interest people in MySpace's declining profile, but the site remains one of the most popular on the web and a viable competitor to Facebook. (Facebook said they may or may not comment on this move by MySpace; we're still waiting to see if they'd like to.)

The goal for the program that Keller shared with us was different. She says that the microformats markup will enable the company to make smarter decisions in highlighting friends' updates and offering users' recommendations.

Keller says that MySpace is working on and will soon deploy technology that closely monitors what kind of friend updates users show interest in. If I often click on your photos but never read your blog posts, or I am very interested in your book reviews but don't care about your events listings, then MySpace will feature those kinds of your updates in my friends' activity feeds more or less prominently. Knowing what kinds of activities are being brought in from other sites will help make that more possible. The same information will facilitate smarter recommendations of content you might like.

That's why Monica Keller says "We don't want to do anything without semantics, to be honest. We can't afford to show a user content on their home page that they aren't going to like."

Watch for these new technologies to be announced in the coming weeks. They could have a big impact not just on the future of MySpace, but on much of the rest of the web as well.