I did a bit of proof of concept work using MEF about a year ago.  MEF is all about composition of providers and consumers.  MEF’s main job is to connect the providers to the consumers so that when the consumer code executes, the providers they require are “just there.”

As trivial as that sounds, it significantly changes how you think about programming.  It forces you to think in terms of composition instead of in terms of plumbing and bushwhacking.  As a result, you can focus more energy on solving your actual problem instead of spending the majority of your time building the plumbing and scaffolding so that you can get to the point where you can begin to solve your problem.

For example, if you’re writing some code and you require “X” to get your work done, you write your MEF code module to declare your need for “X”.  When your module is loaded by MEF, MEF will take care of the dirty details of finding a provider to fill your need for “X”.  The provider may be the one you had in mind when you wrote the code, or it may be completely different, but as long as it implements “X” faithfully, you don’t really care.  The application defines the list of providers to choose from – whether a fixed list determined at build time or a list gathered at runtime – the point is, you and your code don’t need to deal with the how, just declare the what and keep going.

MEF alters your coding thought process from

“I need to figure out how to load and connect to something to get the X that I need”

to

“I need X.  I can rely on X being here when my code executes.  If for whatever reason X isn’t available, my code won’t be loaded so I don’t have to mess with all that.”

This change in thought process is similar to the shift that can and should occur when you go from writing traditional fire-brigade error handling code to writing code in an exception handling environment. For most of the code in your app (the middle layers), you can operate under the mantra of “If execution gets this far, then everything prior to this must have succeeded.  If anything back there failed, it would have thrown an exception so I wouldn’t be here now.”

I’ll see if I can get clearance to blog about my little MEF experiment from awhile ago.

A quick web search on calculating browser window height reveals that different browsers have different ways to find the browser’s window client height.  In Netscape / Mozilla browsers, you can use window.innerHeight.  For IE, some sources suggest using document.body.offsetHeight, but I’ve found this falls short when the HTML content does not completely fill the browser window.  document.documentElement.clientHeight returns the actual window client height in IE.

The jQuery JavaScript library has some handy functions for calculating an element’s pixel location and pixel width and height, with or without consideration for borders, padding and margin.  $(“.myclass”).outerHeight() will give you the pixel height of the first element with a CSS class of “myclass”, including borders and margins.

$(“body”).outerHeight() returns the same value as document.body.offsetHeight, which will be less than the window height in a short HTML document and could be much larger than client height in a scrolling window.

• Novel: multiple independent story lines that you hope will eventually converge to make a point.
• Short story: a limited number of characters with only one point to make
• Essay: tell ‘em what you’re going to say, say it, then tell ‘em what you said
• Tragedy: everything that can go wrong usually does
• Sonnet: ornately crafted for no particular reason
• Ode: behold my skillz, and despair!
• Thriller: I’ve got a  bad feeling about this…
• Murder Mystery: when things go wrong, top priority is on placing blame
• Self-Help: You can do it!  Please do.
• Epic Saga: “Help! I can’t stop writing!”
• Technical Documentation: Useful bits hidden in a sea of jargon, surrounded by a narcoleptic field
• Government Bulletin: Technical docs sans useful bits
• Billboard: all flash, no substance

Since I come from the school of “simple elegance”, I’d have to say that my ideal software’s literary equivalent would be

Comedy: If you have to explain it, it’s not very good.

You could create an event handler method to catch each of the old style events fired by the old code and turn around and fire the corresponding new style event in your API, but who wants to write all that mind numbingly repetitive code?

There is a simpler way.  The two incompatible event patterns do have one thing in common:  the Invoke method.

But first, some background.

Custom EventHandler Types, 1.0 Style

In .NET 1.0 the pattern to define an event property was to define an EventArgs class to carry the arguments of your event and define an EventHandler delegate type which uses that EventArgs class as its args parameter.  Like this:

    public class ActivityCompletedEventArgs : EventArgs
    {
        public ActivityCompletedEventArgs(int resultCode, string result)
        {
            ResultCode = resultCode;
            Result = result;
        }

        public int ResultCode { get; private set; }
        public string Result { get; private set; }
    }

    public delegate void ActivityCompletedEventHandler(object sender,
                                                       ActivityCompletedEventArgs e);

    class Bar
    {
        public event ActivityCompletedEventHandler Completed;
    }

Generic EventHandler<> Types, 2.0 Style

With the advent of generic types in .NET 2.0, the generic EventHandler<> parameterized type was born.  This parameterized EventHandler<> delegate type simplifies how you declare and use event handlers – you don’t have to declare a custom event handler delegate type to match your event args class every time you create a new kind of event.  This is exactly the kind of thing that parameterized types (aka generics) were created to solve. Like this:

    public class ActivityCompletedEventArgs : EventArgs
    {
        public ActivityCompletedEventArgs(int resultCode, string result)
        {
            ResultCode = resultCode;
            Result = result;
        }

        public int ResultCode { get; private set; }
        public string Result { get; private set; }
    }

    class Bar
    {
        public event EventHandler<ActivityCompletedEventArgs> Completed;
    }

However, the downside is that EventHandler<> delegates are not assignment compatible with the old style non-generic EventHandler style delegates.

The Invoke Bridge

Both styles of event delegate have an Invoke method with a signature of (Object sender, EventArgs args), where EventArgs is the arguments class specific to this particular event.  You can use this point of commonality to convert between event styles without too much trouble.  The trick is to use the .Invoke method in one style of event as the callback method registered in the other style of event:

    class OldStyleClass
    {
        public event ActivityCompletedEventHandler OldStyleEvent;
    }

    class NewStyleClass
    {
        public event EventHandler<ActivityCompletedEventArgs> Completed;

        public void blah()
        {
            var obj = new OldStyleClass();
            obj.OldStyleEvent += new ActivityCompletedEventHandler(Completed.Invoke);
        }
    }

The code above hooks up the events so that when OldStyleClass.OldStyleEvent fires, it will fire the NewStyleClass.Completed event.

The main catch to this technique (in C#) is that the reference to the event’s .Invoke method must be made from within the context of the class that defines the event. C# doesn’t allow access to the members of an event delegate outside of the class that defines the event. The rules may be different in other .NET languages.

If you want to use this technique in the opposite direction (to have a new style event fire an old style event), you will need to be able to modify the source code of the old style class that defines the old style event. This is much less common than making old style code to fire new style events.

Whenever I visit my Google homepage now, I have to wade through 5 or 6 JavaScript error notifications before I can do anything.  I suspect the culprit is the Gmail gadget for the Google homepage, as I continue to get script errors while trying to browse email in-situ on the homepage.  The gmail gadget is also missing scrollbars on long messages. None of these problems are present when using Gmail itself, just when using the Google homepage.

As a developer, I have to have script debugging enabled in my browser.  This enables me to debug my web app code in the browser, but it also has the unfortunate side effect of pointing out JavaScript errors on every site I visit.  It’s surprising how much crappy code is out there in production.  Slashdot has degraded into the pretty much unusable range in recent months, and now the Google homepage / Gmail widget is following suit.

The script errors are not specific to IE.  Firefox 3 also notes 5 critical errors in its error console when navigating to my Google homepage. To Firefox’s credit, recording these script errors in a log rather than with popup dialogs is much less intrusive than IE, but that also means that significant script errors can go unnoticed by developers testing their web apps with Firefox.

The errors are:

Error: _IG_AddCustomEventHandler is not a function
Source File: http://www.google.com/ig/f/lZ_kPjC_O4s/lib/libcore.js
Line: 43

Error: _IG_AddEventHandler is not a function
Source File: http://www.google.com/ig/f/irJtX0bmDdM/lib/libdynamic-height.js
Line: 4

Error: _IG_Json is undefined
Source File: http://www.google.com/ig/f/_pVqt4t_Qx8/lib/libviews.js
Line: 1

Error: _IG_Prefs._parseURL is not a function
Source File: http://www.google.com/ig/f/lZ_kPjC_O4s/lib/libcore.js
Line: 78

Error: _IFPC is undefined
Source File: http://www.google.com/ig/f/irJtX0bmDdM/lib/libdynamic-height.js
Line: 2

So, to whoever turned on the new code a few days ago for either the Google Homepage or the Gmail widget for the homepage:  Please review your code and fix the crappy script that you’re dumping on us.  Your developer bretheren thank you for a speedy resolution so that we may get back to debugging our apps instead of debugging yours.

I’ve spoken on networking topics on several occasions in recent years, and at least half of them had some sort of hiccup in network service during the presentation.  Demoing Live Services a few years back in a meeting room with no network connection at all was a bit of a challenge! 

It will be such a relief to finally be able to show web stuff regardless of whether the network is there or not!

“Jinx!” you say?  “How dare you challenge the demo gods so! They will be most merciless upon your head!”  Nah.  All you need to discuss Live Mesh development is a pen, whiteboard, and a light (Don’t forget the light! Demo pixies love power outtages).  In a pinch, even the pen and whiteboard are optional.

If you’re in the SF Bay area and curious about what we’re up to with Live Mesh applications, come on out and join us Wednesday evening and get the scoop!

I’m working on a scenario where I need to process mesh data at intervals. My concern is how I can do delegated authorization in a secure way. How and where do I store the user credentials (or their auth token) in my Windows Azure service? Is there a way of doing interval based processing in the cloud other than Windows Azure (excluding offerings from other third parties)?

You have three approaches to process data in a user’s Live Mesh at regular intervals: 

• An application that runs on the client machine
• A service that runs on a traditional server
• A service that runs in the cloud.

Client Application 

A client application running on the local machine can access the currently logged-in user’s mesh data.  Your app could be written as a desktop .NET Windows application, using the Live Framework SDK to connect to the user’s mesh.  Your desktop app will need to present valid authentication credentials to the Live Framework APIs; to avoid having to store and protect the user’s credentials, use the LiveID SDK.  If the user checks “remember me” and “remember my password”, your app can login on the user’s behalf using the LiveID API’s cached credentials.

You could implement your client app as a mesh-enabled web application, written in HTML+JavaScript or Silverlight.  User authentication is automatic in this situation, since the user must be logged in before they can run your app.  If the user has installed the Live Framework Client on their local machine, they can run your app on their local desktop just as they would a normal desktop app.  When your app is running on the local desktop, it will default to talking to the local cache of mesh data which is synch’d frequently with the cloud when the machine is connected to the network.

These client-side approaches may be sufficient for simple scenarios.  Client side code is convenient to write and doesn’t require allocation or management of server resources, but client side code is at the mercy of the local machine and network connection.  If your users tend to leave their machines on most of the time, this might be good enough, but if you need true round-the-clock processing you need a server side solution.

Traditional Server Application

You could implement mesh data processing in a traditional web server architecture, such as IIS with ASP.NET or Apache with PHP, Perl, or Python scripting.  This will require delegated authorization, and delegated auth requires that your server have a stable domain name.

Delegated authorization requires that the end user approve or opt-into allowing your application to access (parts of) their mesh data.  This approval must take place using a special Microsoft branded web page, so that the user will know that they are telling Microsoft that it’s ok for you to access their data. 

The flow typically looks something like this:

1. Your web page explains what data you want access to, and what you will do with it, and then forwards the user to a Windows Live authorization page
2. LiveID login will interject if the user is not already logged in, then forward to the intended page
3. The user reads the information on the Windows Live web page and chooses to allow or deny access to your site (your domain).
4. The user’s response forwards the user back to a landing page on your web site.  If the user allowed access, this response will contain an authorization token.
5. You store the authorization token in your system, usually paired with the user’s name within your system so you will know which auth token to use to access this user’s data in the future. 

How you store this auth token is up to you, but it should be under physical and network access protection.  At a minimum, you should encrypt whatever table or file you store the auth token in and restrict access to the file to only the administrators and web services that need to access it. You should also avoid transmitting the auth token across the network except when needed, and only via a secure SSL connection.

The auth token cryptographically combines your domain name with the user’s LiveID username.  The auth token can only be used on requests made from your domain name, can only access that particular user’s data, and can only access the kinds of data the user gave you access to.  The user can revoke your access (invalidate the auth token) at any time using the Windows Live web site.

Once you have the user’s authorization to access their data with the auth token, accessing their mesh data is fairly straightforward.  You can use the Live Framework SDK to make data requests of the user’s mesh data from within an ASP.NET server app, or you can make plain old REST style HTPPS requests to the Live Services cloud using your favorite server scripting tools.  You add the delegated authorization token for the particular user in a header to outgoing requests.

And finally, you can schedule your service to check the user’s mesh data on regular intervals, using cron or AT or whatever scheduling tool is appropriate.

Cloud Service

You can implement your mesh-checking logic in a hosted cloud environment, such as Windows Azure, Amazon EC2, GoogleApp, or a variety of other hosting providers.  You will still need to use delegated authorization as with the traditional server scenario and walk through the same steps to obtain the user’s permission and be issued an auth token. The code you write to access the user’s mesh data using the auth token is pretty much the same as what you would write in the traditional server scenario.

Data security is a core requirement of every app, but especially of cloud hosted applications.  I think you’ll find data security is a core component of Windows Azure cloud data services. You can store the username + auth token in a table in Azure’s cloud data service.

Scalability and cost management are where running as a cloud service has a distinct advantage over the traditional server scenario.  Scalability is easy: having the option to fire up additional instances of your cloud service by the tens or thousands as needed to meet demand is a key aspect of large scale cloud hosting that traditional servers in the closet or co-lo’s can’t begin to touch.

If your application needs to be checking the user’s mesh data every 5 minutes all day every day, the operational differences between cloud and traditional server will be relatively small, and perhaps offer no cost savings at all. 

If your application needs to run only during business hours or only on certain days of the week, you can do something with a cloud service that you can’t do with a traditional server, hosted VM or co-lo:  You can turn the cloud service off when you don’t need it, and stop paying for it until you turn it on again.

Anticipating a holiday rush?  You can scale up your customer capacity to massive volume during the holiday shopping crunch, then get rid of it in January and coast by on a shoestring ops budget until the next holiday surge.

If your mesh-checking app needs to check for changes in the user’s mesh data every 5 minutes, your service will be running pretty much non-stop.  If you only need to check 4 times a day, though, you might just turn your cloud service off until the next update interval.

When designing your mesh-checking architecture, be sure to take a close look at the notification features offered by Live Frameworks.  Notifications and data sync metadata could significantly reduce the frequency and amount of work your app needs to do to detect changes.

First, let’s look at what kinds of applications can access user data stored in the user’s mesh (after user consent, of course):

1. Silverlight mesh-enabled web apps
2. DHTML + JavaScript mesh-enabled web apps
3. Server-side web applications (Windows Azure, ASP.NET, Apache, PHP, etc)
4. Cloud-based web services (Windows Azure, Amazon EC2, Google Apps, etc)
5. Desktop .NET apps
6. Win32 apps
7. Win64 apps
8. Linux apps
9. Mac apps
10. Mobile device apps
11. Anything that can make HTTP requests, set HTTP request headers, and process XML responses.  With a little bit of code, your Internet-connected lawn sprinker controller can load its watering schedule from a mesh object in your Live Mesh! 

We provide .NET client libraries to facilitate using the Live Operating Environment (LOE) services in your app, but .NET is not required to talk to the LOE or to specific services in the Live Services cloud – you can also talk to Live Services (and the LOE) with RESTful HTTP requests built on industry standards such as Atom, RSS, JSON, and XML using whatever programming tools you want, from whatever device or platform you want.

Mesh Enabled vs Mesh Aware

A mesh-enabled web app is a DHTML or Silverlight web application that can not only talk to mesh services and access the user’s mesh data, but the app itself is a mesh object deployed and sync’d through the cloud to whatever Internet browser enabled device the user has in front of them.

A mesh-aware application is any other kind of app, running on the client device or on the server, which talks to Live Services and can make use of user data stored in their mesh.  These do not get the benefit of automatic deployment or updates orchestrated by the LOE, but they are also not restricted to the security sandbox of a mesh-enabled web app.

Online and Offline Modes

The user’s mesh data can be accessed by applications when the device is online.  If the Live Mesh client is installed on a device, apps can access user mesh data even when the device has no network connection. Data changes written to the local LOE while offline will be sync’d to the cloud LOE the next time a network connection is available.

Data Sync

The Live Framework automatically synchronizes data changes between the local client and the cloud, in both directions.  The user can select which Mesh Objects are sync’d to which devices in their mesh.  You’d want to sync photos from your cameraphone / mobile device up to a mesh folder in the cloud, but you would probably not want to sync all of your photos in the cloud down to your phone.

Mode Transparency

Mesh-enabled and mesh-aware applications use the same APIs / HTTP request patterns to access user mesh data in the local LOE as to access user data in the cloud LOE.  What changes is the domain name used in the HTTP request (localhost:port versus cloud domain), and that’s needed only when making the initial connection to the LOE.  After that, all LOE requests are relative to the base URL of the selected LOE.  And if you’re using the .NET client libraries, nearly all of that local/cloud selection will be taken care of automatically behind the scenes.

User Authentication, Authorization, and Delegation 

You can use the LiveID SDK to enable users to log into their mesh account from within your mesh-aware desktop or device applications.  You can also use LiveID in your own Windows Azure cloud services: read Windows Azure Integration with Windows Live ID, Active Directory and OpenID.

You don’t have to use LiveID.  If your app is a server-side web app or other service that the end user cannot log into directly, you can use Live Service’s delegated authorization to obtain an authorization token that you can use to access data in the user’s mesh independent of the user’s login state.  The user has to opt in to giving you that token, and can revoke your access (invalidate the token) if you don’t play nice.  The authorization token is cryptographically bound to your domain and the user’s id. 

Mesh-enabled web apps don’t need to do anything with authentication because the user will have already logged in prior to executing the mesh-enabled web app, and the web app lives “inside” that authenticated sandbox context.

Sharing

The user can choose to share a Mesh Object with other users.  If your app writes to a particular Mesh Object and the user shares it with others, your app data can be distributed to the social graph without any work on your part.  Your app can also see who has access to or is sharing the Mesh Object. 

A Few Scenarios

• A desktop .NET application (written in any .NET language) reading and writing app data to the user’s mesh. 
• The same app (same binary executable module) writing data to the user’s mesh while the machine is offline. (local LOE)
• A desktop Win32 application reading and writing from the user’s contacts. (LiveID SDK + raw HTTP / AtomPub)
• A web server app that writes data to a mesh object in the user’s mesh in response to a button click or form submit. (online)
• A headless cloud based web service that updates data in the user’s mesh every 3 hours. (delegated auth)
• A DHTML+JavaScript mesh-enabled web app running in the browser reading and writing data to the user’s mesh. (online)
• A Silverlight mesh-enabled web application running on the local desktop (via Live Mesh client) while offline.  (Offline Silverlight!)
• A DHTML+JavaScript mesh-enaabled web application running in any JavaScript-enabled browser on a smartphone. (online)
• A Silverlight mesh-enabled web application that displays interactive features on current events, updated continually (daily) with new content and code logic (online/offline, data sync and app sync)
• Store your application’s personalization settings in the user’s mesh.  The user’s preferences follow them to any machine they run that app on, regardless of whether your app is a mesh-enabled web app or a traditional installed desktop app.  (Think: student computer lab.  Many machines all configured the same used by many students all demanding to be different)
• Same as previous scenario, but now across different kinds of devices.  User’s preferences and settings sync across PC, Mac, cellphone, etc.
• Briefcase application:  Grab a dataset of client leads into your mesh-enabled sales lead app while at the office.  Review client dossiers while offline in transit.  Update sales contacts and enter purchase orders at client site, while offline.  Sync changes and purchase orders to office (to a cloud mesh object shared with and watched by a mesh app at the office) at an Internet cafe in the airport on the way to the next client. Show next client how to enter orders themselves using your purchase order mesh-enabled web app (the same one you have running offline on your PDA-phone) running in their browser. 

These are just a tiny sampling of the kinds of things you can do with the Live Framework.  There are many more features I haven’t mentioned that add additional dimentions to the sample matrix:  your mesh-aware and mesh-enabled apps running on the client device can programmatically construct resource scripts (expression trees) which can be executed on a server in the cloud (to move large data around on the server without making a round trip to the client across the network); there’s a server-side cross-domain proxy service that lets your mesh-enabled web app (executing in the context of a cloud domain name) “phone home” to your own web server or domain; and so forth.

If I had to name one thing that sets the Live Framework head and shoulders apart from other products that attempt to bridge the online/offline gap, it has to be Live Framework’s data synchronization.  Other tools such as Google Gears can help you run your web app offline, but getting your offline data back into the cloud is left as an exercise for the reader.  In Live Framework, synchronization is a fundamental assumption, a cornerstone of the core architecture.

When data automagically appears in all the places it’s supposed to go, you suddenly find that you have a lot less code to write, debug, and maintain.  You can get back to focusing on business logic and spend a lot less time on infrastructure.

With apologies to ‘The Bard’

“Why does VS upload files to the cloud individually instead of as one zip file?”

VS uploads individual files to the cloud because that’s what the cloud service APIs for application upload require.  When you manually upload an application zip file to the http://lx.azure.microsoft.com developer portal, the developer portal internally unzips the files and uploads them to the actual cloud storage.  The developer portal is just a UI frontend to the actual cloud services backend.  VS tools talk to the cloud services backend.

“What if Visual Studio dies before uploading all the application files?  It seems like updating an app by manually uploading a zip file is a safer, slightly more atomic operation.”

First of all, the goal of tools is to eliminate manual repetitive tasks.  Uploading an app to the cloud certainly qualifies as manual and tedious and something that is going to need to be done a lot (every time you hit F5 to run the app).

If VS dies (or more likely, you lose your network connection) before uploading all the application files, the worst thing that will happen is that you will be left with a debug application resource feed that is incomplete.  VS doesn’t upload files into your existing installed mesh application, it creates a separate debug application resource to upload into and debug from.  This helps ensure that the bits you’re debugging are the bits that VS put there that match your local debug symbols, without any interference from automatic application updates caused by changes elsewhere in the system.

“Once real production apps are being upgraded, something more robust would be nice” 

Visual Studio never debugs or uploads applications into a public, production environment. You’re always operating on an application that is tagged as in “development” mode in the cloud.  When you’re finished with development (and testing) you go to the developer portal and throw a big switch to push your application into production mode, accessible to the general public. 

I believe (not sure here) that pushing the app into production will only expose one version of the application’s resource feed.  If that is the case, then you should be able to continue development of that app in VS because VS always uploads and debugs from a separate (private / nonpublished) debug application resource feed.

“When my app is sync’d to my local machine, does it download the zip file or the individual files of the app?”

The files in your application are stored in the cloud as entries in an application resource feed. When the contents of your application feed needs to be sync’d to a particular device, the sync granularity is at the level of individual files.  The Live Mesh client does not download the zip file you uploaded to the cloud because (as far as I know) that zip file no longer exists anywhere.

A lot of what you see in this CTP release of the tools will change significantly before we release.  For example, the manual process of uploading the app to the cloud to get the app self link to paste into VS will definitely be going away as soon as the cloud implements and exposes the app creation and provisioning services needed by tools.

Our goal for the Live Framework Tools for Visual Studio is to make developing Live Mesh enabled applications as seamless as developing a desktop app.  You create a project, make some edits and F5 to run the app, stop at some source code breakpoints, evaluate some variables, close the app, edit and F5 to run again.  Whether the app is in the cloud or on the local machine will be a footnote to the development cycle you’re used to, not a radical departure.

You can fix the default permissions on your app after you perform the first upload steps in VS and the dev portal.

1. Perform the first-time app upload steps in VS to upload the zip to the dev portal and set the app self link in the VS project.
2. In VS, press F5 again to verify that your mesh app starts up in Live Desktop in the browser, under VS debugger control.
3. Close the Live Desktop browser to end the debug session.
4. Open a new browser window and log into Live Desktop (http://developer-ctp.mesh.com) 
5. Select the Apps page. 
6. Find your mesh app in the list of installed mesh apps.  Click on the name of your mesh app instance to view its details page.

The permissions listed on the details page will look like this:

Permissions
Read access to my Live Mesh object
Read access to my Windows Live Contacts
Read access to my Live Mesh User News

To adjust the permissions to the correct default values, click on the “Edit” link in the top right corner of the panel.

An “Access Permission” page will be displayed.  Click Cancel to return to the app instance list. 

Click on the app instance link in the installed applications list to view the app’s details page again.

The app permissions should now look like this:

Permissions
Read access to my Windows Live Profiles
Read access to my Live Mesh Devices
Read and update access to my Windows Live Contacts
Full access to my Live Mesh User News

Your mesh app can now write to its contacts and news feeds.

This permissions adjustment only needs to be done once after the VS tools have uploaded the app for the first time.  Subsequent edits & updates by VS will not change the permissions.

This default permissions bug will be fixed in the next update of the VS tools.

 Originally posted in the Live Framework discussion forum