I've been trying to use Microsoft's SyncToy for my directory synchronization tasks, and I'm just about fed up with it.  For reasons I can't fathom, it routinely "forgets" what to synchronize.  I frequently synchronize to and from a USB stick, and I find that SyncToy usually wants to copy far more files than have actually been changed.  Like I'll make a couple of changes to some files on the stick, and then for some reason SyncToy thinks it needs to re-copy all kinds of files from both the stick and the computer.  So I end up having to copy files manually from one side to another.  It's a bit aggravating.

I guess I'm going back to TreeComp, a freeware program I first used in about 2003.  It looks godawful but still works better and faster than anything I've seen.  We'll see how it goes on Vista.

I noticed with some concern that the Visual Studio 2008 designer puts an "s" on the end of table names when it builds LINQ to SQL classes.  If you want to disable that, open Tools/Options, go to the Database Tools O/R Designer page, and change "Pluralization of names" option to false.

Note that if you have already generated pluralized classes, you have to force the designer to regenerate the classes by actually changing the names to some temporary value, build, then change them to what you really want and rebuild again.  Otherwise, if you leave the name the same, it assumes it doesn't need to regenerate the classes.

Most of the buzz from Microsoft's PDC is about Azure and C# 4.0.  I don't usually pay too much attention to bleeding edge Microsoft technology until it might actually be used in real-life situations, but I thought I'd break from tradition and peek at these two shiny new things.

Windows Azure Services

There isn't a lot of concrete information available on Azure yet, so there isn't much to say about it.  Conceptually, it's a specialized web hosting service from Microsoft for your ASP.NET web apps.  It's specialized because it's designed for the large numbers of processors and mass storage requirements needed for large-scale enterprise applications (large-scale as in, for example, Amazon or Facebook or Google).

From a programmer perspective, I gather that the main difference from a regular web app is that the details of the OS and hardware your application is running on is abstracted away from you.  For example, instead of your web app reading and writing files with the System.IO namespace, you'll use SQL Services to read and write "blobs."

I personally can't think of any applications I might use Azure for.  (Do we really need another Amazon?)  It would have to be something mandated by a pointy-haired boss-type.

As for the "cloud computing" part of it; well, I've said before that I don't much care for cloud computing.  Besides all the privacy and data loss concerns, the bottom line is that "the cloud" is meant to make life easier for developers, not users.  As a user, I might store a copy of something in the cloud for convenience, but I would never use the cloud as my main work area.

C# 4.0

Recall that C# 3.0 gave us query syntax, extension methods and the "var" shortcut, and tried to change us to functional programmers with lambdas.  With the possible exception of LINQ, I personally have not yet encountered a situation where I thought any of those things would make my code better.

So what can we expect from C# 4.0?  Among other things, dynamic types.  That's right, in the continuing effort to put back all the bad things we didn't like about VBScript and C, the variant and void* is back.  For all those people who simply can't decide how to declare your variables, you can now circumvent all pre-planning and simply write, "void myfunction( dynamic myparam )".  Is that parameter a string?  Is it an int?  Is it a custom object?  Is it an array?  Who knows?  Guessing is half the fun!

I kid of course.  You could assume it's an object of some kind.

I'm sure there are situations where it is more convenient to use "dynamic" than an interface.  (Just like there were plenty of occasions to use void* types and variants.)  Offhand, I can't think of any, but I'm sure they're out there somewhere.

The problem I see with dynamics is that, as with any "advanced" language feature that circumvents the "KISS" principle, it leaves the door wide open for the inexperienced to abuse it unmercifully.  When you go too far down that road, you end up with Perl, a language almost entirely composed of symbols.

It looks like almost all of the new C# 4.0 features were designed to improve COM Interop, which is something I don't have much use for.  I have exactly one COM component project, and if I ever need to use it again, I plan to upgrade it to managed C++.

I do like the idea of finally having optional parameters, though.  That's something I'd use (sparingly!), as long as it compiles down to the .NET 2.0 CLR.

Here's the progress I made on my MMO engine this weekend:

I should probably figure out how to do a screencast or something; it's more impressive when it's moving. :)

A while back I railed against C++/CLI for its nonsensical inability to separate property implementations from the header file.  Well, it turns out you can do it -- it's just not widely reported.  Almost every example of a C++/CLI property shows it implemented in the header file.  But thankfully I stumbled upon an article about this very subject:  Splitting Properties Between Header And Implementation Files In C++/CLI.

Old Class.h:

New Class.h:

New Class.cpp:

The key is the Class::Property::get and Class::Property::set syntax that I'd not seen documented anywhere before.  Hopefully now that there are two articles about this, it will move up higher in Google searches.

Before I embark too far on the insane idea of writing my own MMO engine, I thought it would be instructive to peek at some open source engines out there (gathered from the first few pages of a Google search).

At this point I am mainly interested in the specifics of their network implementation, because that is really the foundation on which everything else is built.  For reference, my design so far is leaning toward UDP sockets with variable-length packed binary structures, conceptually similar to the Quake network protocol if I remember right.  The idea is to maximize CPU efficiency (by avoiding expensive serialization and parsing routines) and minimize bandwidth requirements (by avoiding bloated serialization and parsing routines).

Black-Crystal.  (C#.)  No code releases that I can find, which is too bad, because I would have loved to see their .NET implementation.

Genecys.  (C, CVS Repository.)  The source code is not very easy to read and not very well commented, but I gather (from server/network.c and server/ninterface.c) that the design uses simple text commands over TCP streams.  This is precisely what I don't want to use, because I don't think it will scale very well.

OpenMMOG.  No code releases that I can find.

PlaneShift.  (C++, SVN Repository.)  This is an actual MMO that you can play, which makes it a compelling test case.  After perusing the source repository, it looks to be using UDP sockets (see common/net/netbase.cpp) and message structures similar to my design.  I am validated!  (Although, honestly, it's not so much mine as it is John Carmack's idea from the 1990s.)

Ryzom (NeL).  (C++, SVN Repository).  I can't tell what it's doing because the repository gives me internal server errors ("Rails application failed to start properly" -- figures :).  Based soley on the filenames in the source code, there appears to be UDP and TCP code.  I'm very interested in seeing what it does because it purports to be able to update hundreds of entities in an area with modest bandwidth usage.  I have a number of ideas of my own in that department, and I'm curious if they are similar.

Torque MMO Kit.  (Python, Repository).  (I am not positive, but I think this is actually descended from the original Tribes game engine.)  This appears to be one of the most mature codebases around, but I'm not a Python guy, so much of this is foreign to me.  I can't find any specific network layer -- I think it's probably embedded in whatever application parses the .cs files, but there's no source code for that.  In any case, an entire implementation of an MMO game is there, so it's a good reference to have handy.  It would be interesting to try Minions of Mirth to see how well the engine works.

vbGORE.  (VB6, Downloads.)  Yeah, I know, it's written in VB6, but I downloaded it anyway.  It actually looks surprisingly mature.  Digging into the GOREsock\GameClient\GOREsock.ctl code reveals they're using TCP byte streams.  I can't make much sense of the rest of the codebase, but there might be something useful in there somewhere.  I'm not going to install VB6 again to look at it in depth, though.

WorldForge.  (C++, Downloads.)  WorldForge appears to be well-known, but I can't find any real games based upon it.  It's broken into a number of distinct libraries -- the network library is called "Atlas," and it appears to be a highly generalized API, which usually means scope creep from trying to be everything to everybody.  It looks like it's using a TCP stream and serialized objects, encoded as XML or "packed" (see the Atlas::Codecs namespace).  Unfortunately, the code looks like it's getting close to the "big ball of mud" stage of entropy. :)

Quick, which one of the following implementations is faster to use in a time-critical section of code:

Implementation 1:

Implementation 2:

Answer:  The second one, by about 33%.

Results:

Method1: 20962096146
Method2: 13987606779

So I decided to write an MMO game engine*.

No, really.

Okay, I know, I know, this is the fifth or sixth time I've started a game engine project like this, and it will probably end up the same as all the others:  Nifty ideas, but without considerably more time and structure and funding -- and, you know, an actual game idea -- it will end up in source code purgatory, picked over for an occasional gem of an idea but otherwise left to rot.

Why an MMO and not something simple like, say, Space Invaders?  Well for one thing I've already written a couple of different 2D game engines (now residing in purgatory) so there isn't a lot to explore there.  Beyond that, MMOs are more interesting to me because they have a much broader variety of technologies to explore.

As usual, I'm going to build most of the framework with .NET since that's the quickest way for me to get a prototype up and running.  I'm not planning to use any third-party game engines (Not Invented Here!), but I do want to use a 3D rendering engine for the client (which just by itself represents a whole set of challenges).  And by the way, no, I still don't have a game idea (well, that's not entirely true, but certainly nothing more than a vague idea) -- I'm only interested in the underlying technology at this point.  And if anyone is reading this that does have a game idea -- no, I'm not interested in developing your game (unless there's a decent salary attached, of course).  This is purely an intellectual exercise.

This should keep me busy until... well, until the next shiny bauble comes along to grab my attention.

* If you don't understand the ramifications of that statement, it's roughly equivalent to me saying, "so I decided to memorize the encyclopedia" or "so I decided to perform a heart transplant."

I just read about Sitemap.xml on Coding Horror.  I'd never heard of it before (yeah, I'm not exactly wired into the whole SEO thing).  Anyway, I just implemented a site map for my page, for what it's worth.

This also led me to Google's nifty Webmaster Tools page which, again, I'd never seen before.  I've made a few small tweaks to my page titles to be a little more Google-friendly.

By the way I'd like to apologize to anyone who has viewed my site recently with Internet Explorer 7.  Sometimes it rendered very badly, randomly writing text all over the place, shifting boxes around and generally looking ugly (see below).  It had something to do with an overflow:hidden CSS attribute in the rounded boxes, which apparently is not well liked by Internet Explorer.  I had to implement one of those "conditional comment" hacks to use an alternate style sheet for Internet Explorer browsers.

For future reference:  I had always heard that there were cases where finally blocks were not run.  The other day I actually witnessed one of those situations:  In a .NET console app, if you hit CTRL-C to exit the application, finally blocks are not executed.  Fortunately garbage collection will still handle standard cleanup of objects for you (at least I assume so).  But if you need to do something special you have to use the System.Console.CancelKeyPress event, like so:

System.Console.CancelKeyPress += delegate { Cleanup(); };

Be careful because it runs in a separate thread -- the main thread is not interrupted and won't actually stop until the CancelKeyPress handler returns.

Unfortunately, I found no way to handle the situation where the user clicks the close button (the red X) on the console window.  It skips both CancelKeyPress and all the finally blocks.

I learned a new software development term the other day:  "Agile Wall."  For those of you who aren't into renaming things that already have names just to sound more important, it is:  "A bulletin board with project notes all over it."  Okay, okay, the notes are supposed to be arranged into three columns for "todo," "in progress," and "done."  Yeah, I can see how it's a totally different concept now.

Previously I wrote about Opera 9.5.  Since then, I've been using it for almost all of my browsing at home (at work we still have to use IE6 *rolls eyes*).  So far I've only encountered two real problems with it.

Of course, every now and then, you still run across some sites that refuse to work with anything but Internet Explorer or Firefox.  Most of the time it's a bank or some other kind of financial institution.  (I find it somewhat ironic that banks usually have the worst, most incompatible, most insecure web sites around.)  It's not really a problem, but it is sort of annoying to have to load up another browser.  It'd be nice if Opera had an "Open Link in Internet Explorer" option.  Oh, hey, a quick Google reveals there is a way to do just that.  Sweet.

More annoying is the way that Opera handles RSS feeds and XML.  As a programmer, I look at XML all the time.  And as a programmer who has written software to read RSS feeds, I look at RSS feeds all the time, too.  Opera does an admirable job of recognizing RSS and offering to add feeds to its internal RSS reader like other browsers, but that's not what I want it to do.  When I click on an RSS feed link, I almost always want to look at formatted content or at the underlying XML.  Unfortunately Opera does a miserable job of displaying XML in the browser.  It crams everything together into a big page of unreadable mush.  So for this I'll also have to use the aforementioned Open in Internet Explorer menu.

I had previously written that I tried GhostDoc but removed it because it didn't write very useful comments.  Well I re-loaded it today because it does have one very handy feature:  Adding comments to classes that implement interfaces.  It's incredibly tedious to copy comments from the interface code to the class code, but with GhostDoc you just have to right-click on the class member and hit "Document This" and it will automatically bring the comment from the interface to the class.  Pretty cool.

I'm starting to learn a little bit about LINQ.  I am only doing this because I was starting to learn a little bit about the forthcoming ASP.NET MVC Framework by watching some handy screencasts, and the authors of the framework seem to think that we should all be using LINQ, too, so amidst the discussion of the MVC Framework they throw in quite a lot of tutorials about LINQ.

Based on all the hype built up around it over the years, you'd think that LINQ was the second coming.  It's nice, but it's not quite all that.  To understand what it really is, first let me show you a simple SQL query:

SELECT * FROM customers WHERE state='VA'

This query will return every customer record where the customer's address is 'VA.'  It can't get any simpler than that.

Now you might be wondering why invent LINQ when SQL works just fine?  Well, the problem for us application programmers (as opposed to people writing stored procedures or typing queries into Management Studio) is that we have to do some extra work to send that query to the database and get back results in a manageable format (namely, in a collection of objects instead of a flat stream of bytes).  We have to write code that looks something like this (super-simplified for illustration):

SqlCommand command = CreateCommand( "SELECT * FROM customers WHERE state='VA'" );
SqlDataReader data = command.ExecuteReader();
List<Customer> results = new List<Customer>();
while( data.Read() ) {
Customer customer = new Customer( data );
customers.Add( customer );
}

That will get us a collection of Customer objects that we can work with.  It's not particularly difficult, but it's kind of ugly and awkward.  Normally we try to hide those awkward details behind a data access layer so it doesn't distract us from our application logic.  With the details hidden, we might end up writing application code that looks like this:

IEnumerable<Customer> customers = datalayer.GetCustomersFrom( "VA" );

That worked fine, but now we have a whole new paradigm in LINQ.  Now we don't have to wrap our queries with extraneous code.  Here is the same concept as the above SQL query, written as a LINQ query:

var customers = from c in db.Customers where c.State=="VA" select c;

The cool thing is you can put that right inline with your source code, and what you get back from it is "customers" -- an enumerable collection of Customer objects.

How's it work?  Well, when you get right down to it, it's basically just another data access framework that hides the messy details of querying the database, just like all the other data access frameworks out there.  The only things that are different about this one are, 1) it's built by Microsoft, and, 2) it's integrated right into the language.  (Those are two powerful incentives to use it, by the way.)  But there's nothing really magical about it -- behind the scenes, LINQ to SQL queries are transmogrified into method calls that eventually build SQL statements, send them to the database, instantiate Customer objects, and populate them with results from the query.

But enough of that.  Let's talk about the LINQ query syntax itself.  I find it puzzling.  For example, in LINQ query syntax, we have to specify where to look before we specify what we're looking for.  In SQL, it was a pretty straightforward "select stuff from here."  But in LINQ, it's backwards -- it's "from here, select stuff."

We also have to specify the search criteria in the middle.  In SQL, it was "select stuff from here with this criteria."  In LINQ, it's "from here, with this criteria, select stuff."

Furthermore, we have to reference the name of each row entity, as in "from each row named x in here, select stuff."  I can only speculate that that becomes more of an asset in complex queries, but in my experience, simple queries are much more common than complex queries, so it seems like needless redundancy to me.

In short, LINQ is a handy shortcut if you're working with Microsoft .NET 3.5 technology and nothing else.  (It's almost entirely worthless if you aren't.)  For myself, I can see the benefit in understanding the basics, and I'm sure I'll enjoy working with it where possible, but I can't see myself expending much effort in becoming an "expert" on LINQ.

At this halfway point of the year, I thought it would behoove me to examine how I'm doing on my programming goals for this year.  Back in January, I wrote down some things I wanted to work on this year.  I didn't publish it, so you'll just have to trust me when I say that those things were:

• Write more unit tests for my home projects.
• Start migrating towards Microsoft Visual Studio 2008. Install at work, too, though I doubt I'll be able to use it for anything but experimentation.
• Learn the basics of LINQ without sacrificing my SQL skills.
• Learn what the heck Windows Workflow Foundation is and why Microsoft thinks it's useful.
• See if Windows Presentation Foundation is really superior to WinForms or just "different."

Results So Far

"Write more unit tests for my home projects."  I haven't done very well on this one.

"Start migrating towards Microsoft Visual Studio 2008."  I have been using VS2008 exclusively at home since February, but I'm still stuck with VS2005 at work.

"Learn the basics of LINQ without sacrificing my SQL skills."  Have done nothing on this yet, although I recently identified a place in one of my projects that would be a good place to start learning.

"Learn what the heck Windows Workflow Foundation is and why Microsoft thinks it's useful."  I did a cursory examination of it, but I do not yet know why Microsoft thinks I should spend valuable time learning it.  Am still not clear why a "workflow" is any different from a "program."

"See if Windows Presentation Foundation is really superior to WinForms or just 'different.'"  I ported an old .NET 1.1 project to WPF and found it an enjoyable experience, although VS2008's WPF support doesn't feel very mature to me yet.

Revised Goals For 2008

I will now revise my list for the rest of the year.

• Learn the basics of LINQ without sacrificing my SQL skills.  I think this will be a useful job skill, but it is still imperative that SQL remain the top priority.
• Acquire Microsoft MCTS certification.  I have been putting off studying forever, so I'm going to have to just go ahead and schedule a test to force myself to study.
• Learn some Silverlight basics.
• Learn some Flash basics.  In all my web development years, I've never had an occasion to create a Flash animation.

I downloaded Opera 9.5 the other day and I have to say I'm pretty impressed.  I've wanted to try Opera for years, but I just never got around to it.  Now I'm sorry I haven't been using it all along.

At it's heart, Opera is basically just like every other browser:  You load pages, and it renders them in a window.  Every mature browser should render every page identically, and Opera so far renders everything just fine.

The big advantage that sticks out to me is the application speed.  The "feel" of the program is noticeably faster than Internet Explorer, in terms of navigating the menus and dialogs and tabs and so forth.  This is how an application should be, considering all the horsepower in modern computers.  Sadly, most Microsoft software -- and almost all open source software that uses those crazy complicated skinnable GUI libraries to run on different operating systems -- is so bogged down with layer after layer of APIs that the software feels incredibly sluggish even on a fast computer.

Opera seems to render page content much faster, too, although I admit that is probably the result of their design choice on rendering images of unknown size.  Internet Explorer 7 waits until it's downloaded all the images of unknown size referenced on a page before it will try to render the page, which results in a longer delay before seeing any part of the page.  Opera (and Firefox) shows you what it knows about the page and fills in the images later, which results in a much faster feel, but the tradeoff is the possibility of the page shifting around to fit the images as they load.

I like the "speed dial" feature a lot, too.  In IE7 and Firefox 2, when you open a new tab, you just get a big white empty page, then you have to navigate where you want to go.  With Opera, you get a "speed dial" page with lists nine customizable sites that you can just click on and go.  Also, at any time, you can just hit CTRL and a number and the speed dial page comes up in a new tab (like, instantly).  Pretty cool.

(Oops, I just ran across a Javascript compatibility issue in one of my web sites... I guess it can't all be sunshine and roses.)

I saw an article by John Dvorak -- someone I usually find pretty abrasive -- in the latest PC Magazine (it's not online yet) that I actually agree with.  He was (again) putting the smack down on computing "in the cloud," which is yet another term for (basically) the trend of conducting business by running applications soley in a browser on the web.  (BlackBoard is one example of this type of software, fyi.)  Personally, I -- and most likely any programmer over 35 -- think this is a step backwards in the evolution of software technology, because we are simply re-creating the old days of dumb terminals connected to a mainframe.

Now admittedly, as a software developer, there is much to like about the cloud.  It's new, it's fun, it's hip.  It's quick and easy to create applications.  We have nifty WYSIWIG tools that do a lot of work for us.  It's stupefyingly easy to push software updates out to the customers if/when we make a mistake.  (Actually, we don't even have to push software farther than our own servers.)  We don't have to wait for quality assurance.  We don't need to hire beta testers.  We don't have to write a manual.  We don't have to burn any CDs or mail any packages.  We don't have to wait until the software is even finished to start selling it!  All of these are huge incentives for developers (and entrepreneurs).

But there is much to dislike about the cloud as well.  Even from a developer perspective, I find that the combination of HTML, CSS and JavaScript is a painfully archiac software delivery system.  I thought Java applets held some promise, but for some reason (probably boiling down to Microsoft business practices) they never evolved beyond web-based arcade games.  Flash/Flex is another attempt, but I think it's a technological Frankenstein's monster and probably doesn't deserve to evolve.  Silverlight holds some promise in shifting the development platform forward, but I doubt it will become any kind of standard outside of the Microsoft universe.

Of course, the developer experience shouldn't drive the market... the user experience should.  You would think with the rising popularity of the cloud, the user experience would be second-to-none.  Sadly, as a user, I find that running applications in the cloud is a frustrating experience.  The network is slow and fails frequently.  My data might be lost forever at any moment.  Even worse, my data might be mined for innocuous or nefarious purposes -- by corporations or governments or hackers or disgruntled employees.  Corporate firewalls could block access to the cloud.  And let's not forget the ubiquitous advertising found in cloud applications.  Even if there was a killer cloud app, eventually someone will buyout that company and, chances are, the app will go downhill.

Unless I was dirt poor, I can't imagine a time when I would choose to use Google Docs over Microsoft Word, or Yahoo Mail over Outlook Express, or Photoshop Express over Photoshop.  It's not that there's anything particularly wrong with Google Docs or Yahoo Mail or Photoshop Express -- in fact, they are top-notch examples of cloud software.  It's just that they are inherently limited by the cloud environment and its problems, and I expect a lot more from my software.  Why do you think services are starting to offer local data synchronization?  Because everyone knows deep down that it's better to store data on the user's computer instead of out in the cloud somewhere, beholden to the whims of the network gods and market forces.

Joel Spolsky said that most people only listen to podcasts while they're distracted.

"People who listen to podcasts, it's not like they've carved out an hour from their life so that they can sit in their armchair and listen to it. You know, they're working out, they're taking a walk, they're driving to work or driving back from work, they're in the gym, any kind of situation where you can listen to something in the background but not really give it your whole attention. You can't be watching it. That's pretty much the entire market that podcasts are ever going to have, the same as the radio market."

Now admittedly, I haven't listened to very many podcasts, but if that's true, it would explain why podcasts aren't very popular. Joel is basically saying that podcasts are generally so boring that you can't stand to listen to them.

When I envision a podcast (and I have envisioned creating a podcast), I don't see it as just a boring recording of a conversation -- I see it as a show. I imagine families gathering around their old time radio cabinets and being entertained for however long the show runs. I see it as something that the listeners should pay attention to, in other words. I guess I'm just weird.

I've been following Jeff Atwood's Twitter feed for a little while now. I find that I enjoy his blog much more than his tweets, which sometimes tend toward preachy elitism. For example, in a recent tweet he said:  "[T]he desktop is dead. web apps won," referring to the years-old debate about desktop apps vs. web apps, or thick clients vs. thin clients, or whatever you want to call it.

Web apps are certainly the fad for startups right now, I'll grant you that. If I were a venture capitalist, that's definitely where I'd be throwing my money away, and if I were a programmer (which I am), that's where I'd be concentrating most of my skill set (which I am).

But does that mean web apps "won?" I guess it depends on how you define winning. Are web apps popular? Sure. But are they technologically superior to desktop apps? In a word, no way.

Web apps are "winning" only because that's where the easy money is. Some of that is driven by simple laziness: It's much faster and easier for an adventurous startup company to build and sell (advertising for) a cool web page than it is for them to build and sell, say, an innovative new word processor for Windows. Everyone knows it's technically possible to build a better, faster, smarter word processor, but who in their right mind would try to compete with Word?

For myself, there are plenty of applications that I prefer to run locally on my computer. Like, basically everything I do on a computer. Writing software? Check. Writing a document? Check. Writing music? Check. Writing this blog post? Check. Writing an email? Check. Playing a game? Check. Browsing the web? Che... oh, okay, you got me there. Almost everything, then.

You might be asking why in the world I would possibly want to do any of that on my desktop when I could fire up a browser and go to Google Docs, WordPress, Yahoo Mail, or (insert any one of a million Web 2.0 sites with a silly name)?

Answer: Responsiveness, stability, and even more importantly, data ownership.

Does anyone really think that fetching code and data from a server somewhere out there on the Internet will ever be as fast and reliable as fetching it from a local hard drive? Sometimes network latency is not anything to worry about in an application (eg. data entry apps), but most of the time, people want things to happen on their screen right now. I've lived through the days when you had to watch the computer draw interfaces pixel by pixel on the screen, and believe me, I don't want to repeat it. Even my wife -- who I think is representative of the typical computer user -- is often frustrated by how sluggish web pages load even over broadband.

But even if GMail ran exactly as fast as Outlook Express (and it's close) and never, ever went down, there is still the philosophical issue of data ownership. The bottom line is that I want my emails on my hard drive, not Google's. I don't want to relinquish the responsibility for the safety of my precious, precious data -- my intellectual property. Many people probably don't care, and maybe some are even happy to outsource the job of data management to nameless, faceless foreigners working for pennies a day. To those people I say: Good luck with that and I hope the startup company of starry-eyed marketing school grads you're depending on stays in business forever. (Oops, I think I just dissed 99% of all Web 2.0 startups.)

The way I see it, the only way to make web applications competitively fast and responsive is to keep the data on the servers with the application. So users need to ask themselves: How important is my data to me? Do I really own it or not (not just legally, but physically)?

To put it another way: If you owned a car, would you store it in someone else's garage? Some people do. Some people (like me) wouldn't dream of it.

That's why I think there's still a place for desktop applications.