>
If the remote possibility for the need to scale was present in the original spec, then it was incorrectly architected.
>

Hypo....

There is a 1% chance that the app has to be 100% web-enabled. This I think you would agree is a remote scenario. Futher, presume that it would cost an additional $50,000 to architect the app so that it could go to the web.

Budgets are not an infinite resource. In this case, I have to make a decision to choose between required features or the correct architecture based on a remote need.

I suppose from a technical/theorhetical perspective, you could argue the app is incorrectly architected. From a financial/practical perspective, the app is correctly architected.

Erik, it depends on your perspective as to what is correctly vs. incorrectly architected. Remember, development has to be funded.

My argument is that COM does just fine. COM and XML works. I seem to recall ads from 2 years ago, hearlding WinDNA as THE way to architect your apps for the the Web. Now that we have spent the better part of 2 to 3 years, have we now awoke from a peaceful slumber to find out we were wrong?

My point here is not to debate whether .Net will be a good thing or not. Rather, my point is to say that COM is not bad...



>
Huh? How do you implement com through a firewall? I'm not talking about punching holes, I am talking about port 80/443? Without writing a lot of code on both the client and the server side, you can't.
>

How do people do it now???? Seems to me that folks have been able to things to work now. Why is that? The COM components are behind the firewall. I don't get this argument that COM does not work with firewalls. Make me understand....

>
Translates nicely into 'a lot of extra work' gets around the DLL hell issues. THe fact that you know how to work through a COM versioning issue has nothing to do with the fact that the problem is commonplace, and is a PITA even for those that know exactly how to solve it.
>

Problems will always be commonplace - whether the technology is old or new. I am not saying that .Net will not be able to solve these problems. However, I am not going to rely on biased opinons. Rather, I am going to wait for the true arbiter (sp..) of truth - real experience....


>Yeah, they're writing their own code to do it. Have you ever written one of these apps? It's not trivial. (It's getting easier and easier now that I have my own framework to deal with it, but nonetheless, my framework has a lot of code).
>

Now that your framework works, would you throw it away on something that is not tested? Or, would you wait and see???