[UPDATED MAY 4] Corrected info about how the View Storage Accelerator Works
Today VMware released the details of the next version of View, called version 5.1. (They also announced that Horizon App Manager is available for on-premises deployments and that Octopus is available in public beta form. Jack Madden covered both of these stories on ConsumerizeIT.com today.)
In terms of major features, there's not a lot new for View 5.1. The main new thing is that vSphere's Content Based Read Cache is now available for View, (though with desktops they call it "View Storage Accelerator" (VSA) for some reason). Originally slated for View 5.0 and pulled at the last minute, View Storage Accelerator uses RAM on the VDI host to cache frequently used disk blocks. This provides better experience with fewer read operations going to the primary storage. [UPDATE] This cache is based on the content of the disk blocks, so if it finds any blocks that are the same, it can consolidate them in the cache. This means that in addition to being able to cache the "master" copies of Linked Clones, it can cache identical blocks from random personal VMDK desktop files. This is huge, and a topic I'll cover more in the future. [END UPDATE]
Anyway, VSA is probably the biggest new feature of View. They also announced that you can use View Persona for physical machines, but they stressed the main use case for this is for migrations from OSes or migrations to VDI. (The way Persona works today prevents a user from being logged into two desktops at once with it anyway, so it's not like Persona is getting anywhere near AppSense or RES yet.)
Finally, there's now a View desktop version of vCenter Operations. First announced at VMworld Europe last year, vCenter Operations for View does pretty much what you'd expect it to—real time monitoring and health checking of View environments. The new View version includes the ability to dig into PCoIP performance—something that's been a bit of a black box in the past.
When it comes to clients, last year VMware separated the development of the View server components from the clients, enabling them to release clients on a quicker schedule. Now they've got clients for Mac, Windows, Linux, Android, iPad, Kindle Fire, and Cius. (Yet still no iPhone client?!?)
But perhaps the biggest thing we recently learned from VMware (thanks to Vittorio) is that they are planning (in the future) to deliver single remote Windows applications via PCoIP, and they will also deliver complete remote Windows desktops via HTML5. That's huge. Right now you can only connect to a complete remote Windows desktop via PCoIP. VMware demonstrated technology they're calling "AppBlast" which delivers single applications via a browser, but that was HTML5 only. So basically in the future we'll be able to connect to single remote Windows apps via PCoIP or HTML5, and complete remote desktops via PCoIP or HTML5.
The other interesting thing about the announcements is the fact that this is NOT an isolated announcement about View. VMware spent a lot of time talking about the grand integration of Windows, web, native mobile apps, and cloud-based services. View is only a small part of that which kicks in only when remote Windows apps are needed. Moving forward we'll see less and less on View (in terms of it being a standalone thing), and we'll so more about this unified app, data, and configuration delivery which combines everything.
Oh, and one more thing. VMware now claims that they have more public reference customers than Citrix with more than 5k seats deployed. I can't say whether that's true or not, but I know that I asked my contacts at both Citrix and VMware for lists of public references with >7k seats, and VMware got back to me right away with a pretty long list. So they're doing something right over there.
And one more additional final last thing: View 5.1 doesn't seem to include anything new around PCoIP. I don't know about you, but I'm a big believer that since View 5, the protocol war is over. PCoIP is fine. HDX is fine. Even Quest EOP is fine. (And Windows 8 RemoteFX will be fine.) Sure, there are situations where one might shine over the other, but I don't think any VDI projects are failing now because the company picked the wrong protocol.