Sunday, March 02, 2008

Choosing a technology for an application

The more work I do around WPF "smart" clients the less I believe they are the future. Maybe it's because I'm working on an application that I truly believe is using the wrong technologies and should be an application but I miss the freedom I felt writing web apps.

I know there are a bunch of reasons for writing smart-client - offline, being one of them, but I think that reason is starting to look a little shaky given Google Gears... Now if Silverlight lets you run Sql CE (or equivalent) on the client I see that as one more reason not to write chunky fat clients.

Using Uri's in CAB

Recently I was thinking about a neat addition to CAB that would allow a user to use a Url to "deep-link" into a CAB application (CAB as that's the technology I use at work).

The way I see it working would be:

Use a pluggable protocol to register my application with explorer.
Create a common url syntax to link a Uri to a Cab event
When the application starts follow one of two paths:

1. If not already running then start up and pass the Url to the Url launcher service.
2. If not already running then open an ipc channel listening locally on port whatever
3. If already running then connect to the ipc channel and supply the url.

Originally I thought that you could use the uri to directly create a CAB work-item. This is impossible to do right though. You don't know where the work-item should live in the hierarchy, if it is single instancing or multiple, or any number of contextual issues. Using a Cab event is bullet-proof though. Raise it globally and the subscriber can choose exactly what they want to do with it.