Microsoft Live Labs released Volta today. While all the stuff about distributed application development is true, I fear people are missing the core feature offered by Volta:

Volta turns the code you write in C#, VB.NET, or just about any .NET language, into JavaScript that runs in potentially any web browser.

That's right, you can get all the advantages of using a strongly typed programming language and can still target any browser! No special browser add-ins are needed! Volta produces 100% pure JavaScript code. Currently only IE and Firefox are officially supported, but this isn't an inherent limitation of Volta.

Volta does this using a "re-compiler" that turns MISL (the .NET CLR's "assembly language") into JavaScript. First you compile your code into MISL (using the standard C# or VB compiler) and then Volta turns the MISL into a bunch of JavaScript files. As event handlers and other code on your web page executes, these files are loaded into your browser as needed. Basically, the CLR's on demand "type loader" functionality is reproduced by a script provided by Volta.

While I actually enjoy the dynamic nature of JavaScript and all the tricks it enables, I still think Volta is a major step forward for web application development. This is for one simple reason: large volumes of strongly typed code are much more maintainable then large volumes of JavaScript code. This is primarily because with strongly typed code, when you make a change, it is much easier to locate and fix all the other parts of the code impacted by that change. The compiler helps a lot and the strict encapsulation offered by languages such as C# and VB makes the impact of changes much more predictable.

I also believe that it is much easier to produce stable, high quality, and extensible shared libraries using a strongly typed programming language. Language features such as interfaces and type inheritance with virtual methods are critical parts of any sophisticated library design.

In the context of the current crisis around Facebook Beacon, it is interesting to think about how such feeds could evolve into a much more comprehensive "life logging" system.

Suppose that:

1. Just about everything you did could get logged. Everything you did at any web site, everything you did with any application, everywhere you went and the things around you (via your mobile device), the shows you watch on your cable tv, the purchases you make using your credit card, etc.
2. You could easily choose what events to not log at all, what ones to log to a private store, what ones to share with your real friends, and what ones to share with everybody else.
3. You had powerful tools to search and visualize your private event log that would (eventually) contain years of data. Think of your private log as a digitally augmented personal memory.

Facebook Beacon and it's hand full of client web sites is just the tip of the iceberg. There are all kinds of data sources out there just waiting to be leveraged by such a system.

How private and secure would your personal log need to be before you trusted it? No data mining by advertisers at all? Anonymous data mining ok?

What would be needed to really give you control over all the data you produce? Facebook's easy to miss toast with its default to public policy clearly doesn't cut it.

Would the value of being able to do search over the details of your past ever justify collecting all this data into one place, no matter how secure that place is and how much control you had over it?

It looks as if the project I worked on before joining Live Labs is being announced today. Congratulations to my ex-team! Of course it had a much shorter and more interesting code name then: Yona.

The part I worked on is the OMA-DM server at the heart of the product's device management capabilities. This server interacts with devices over the Internet to perform the management tasks requested by other components of the system. It keeps track of the state of these tasks so they can be restarted should communication with the device be interrupted.

Working on that service gave me an opportunity to work with SyncML. SyncML is RESTful in that it defines a small set of verbs (get, add, replace, delete and execute) that operate on a large universe of entities identified by URIs.

However the HTTP binding for SyncML shuns HTTP's verbs and does everything with POST messages that contain multiple SyncML operations. I suppose some people would say this makes SyncML non-RESTful or, at minimum, that it isn't a very good HTTP citizen.

But, since it was designed to interact with devices which can be slow and relatively dumb, SyncML had some interesting requirements it had to meet. You don't want to have to do any more round trips over the network then necessary when establishing a connection can have lots of latency and each message eats up the device's battery power.

Another interesting aspect of SyncML is that it allows operations to be grouped into atomic units of work. This is very important when changing something like the settings the device uses to connect to it's network. A partial change would take the device offline, preventing any further remote management.

Modeling this behavior using multiple HTTP requests/responses would require the device to keep a lot more state over longer periods of time, something that can be a huge problem given the limited amount of available memory in many devices.

SyncML's URI space is open-ended and very flexible. A number of standard URI groups have been defined (that, and a security model, is mostly what you get from OMA-DM).

Note also that SyncML and OMA-DM are industry defined standards, not something Microsoft made up. They are implemented to at least some extent on most cell phones as well as many other kinds of embedded and remote devices.

When Listas Toolbar's Show Clippings button is clicked, it highlights the clippable parts of the page as shown below:

As you can see, the highlight is a layer above page content. When you mouse over a highlight, the Add and Close buttons are shown.

You can click on the Add button to add the clipping to a default list or click the little "drop down" arrow in the add button to add the clipping to a specific list.

Due to the way your web browser works, these clipping highlights keep you from clicking on any links under the highlight. When you add the clipping to a list the highlight is removed, allowing access to the links underneath it. To remove the highlight without adding a clipping to a list you can click the close button in the upper right corner of the highlight.

We considered a number of alternative designs when developing the toolbar. One option was to always insert the Add button into the page content itself instead of having the show/hide clippings action. Our concern was that this additional button would ruin the carefully designed look of the web pages you visit.

The layered approach adds the inconvenience of having to explicitly choose to show/hide clippings, but has the advantage of making it clear that the add button is provided by the toolbar, not something provided by the original page. Also, the highlight approach helps to clearly identify exactly what will be clipped and, because you don't have to worry about finding a good place to insert the add button, makes creating clipping definitions easier.

What do you think? Are the advantages of the highlight approach worth the inconvenience? Does having to click show/hide clippings make the clippings feature too much trouble?

We want your feedback! Please add comments to the Clipping Highlight Feedback list.

Security

One of the goals of the Listas Toolbar is to enable some Greasmonkey like functionality without having to download JavaScript code to your computer. The fact is it just isn't safe to allow scripts contributed by the community to be distributed to other people's computers.

Instead of using script code to find interesting elements in a web page, the Listas Toolbar's clipping definitions use an XPath expression. This XPath is evaluated against the page's DOM, not the page's source HTML.

So, when we enable community sharing of clipping definitions, we'll be distributing XPath expressions not script code.

Ease of Creation

Another goal of the Listas Toolbar is to allow a large number of people to create clipping definitions. The toolbar provides an UI that lets you drill down to the interesting parts of a web page simply by clicking on what you want to be a clipping. Behind the scenes, the toolbar constructs an XPath expression that identifies the part your clicking on. Here is a video of defining clippings for the Windows Live search results:
 
Video: Listas Toolbar Define Clippings in Automatic Mode

While this "automatic" mode works for a lot of web sites, there are some that are too complex for the heuristics we use. For such sites the "power users" among us can enable the advanced mode which allows them to view the document's HTML element tree and edit the XPath directly. Here is a video of advanced mode in action:
 
Video: Listas Toolbar Define Clippings in Advanced Mode

We felt that using XPath instead of JavaScript for clipping definitions would make the advanced mode accessible to more people, but it does come at the cost of flexibility.

What do you think? Try defining clippings for a few of your favorite web sites. Did the automatic mode work OK for you most of the time? For which sites did you have to switch to advanced mode and why? In advanced mode, were you able to work out the XPath that did the trick?

We want your feedback! Please add experiences to the Clipping Definition Feedback list.