>With respect to COM not scaling. I think this is a bit of an open-ended statement. Is there something intrinsic about COM not scaling, or is it in the implementation? Is the burden too much on developers that they have to know too much? Is this a problem with COM per se, or in the implementation of COM?
It's definitely a problem with COM. The implementation in VB and VFP gets in the way of having COM work the way it really was meant to be. The architecture works fine for inproc same process components, but it falls apart quickly when thread or process marshalling is involved. Both VB and VFP require cross thread marshalling in order to run in IIS, which is slow and very difficult to write code for. Read that as error prone, even in the system components. Most of the problems in ASP and COM components are related around this very problem. As you well know, this has been a pet peeve of mine for a long time. I know because I've built on that same infrastructure and I know exactly what goes on behind the scenes.
You're right scalability is relative especially these days in super hardware you can buy for $1000 or so. But still, look at the stability issues with ASP and COM and MTS/COM+ and COM components written in VB and VFP and you can get an idea. Add to that the admin nightmare (shutting down Web servers just to update a component - please!), security issues and you have something that becomes very complex for the average developer to get right. I'm not talking about somebody learning - I'm talking about an otherwise well rounded developer.
.Net tries to address most of those issues by doing away with all the admin stuff and putting it where it belongs - in the OS not in the application components you build.
Again, we won't really know whether they succeed at doing this well or not until we have something that works better than the PDC preview.
>Robert has often told me the fundamental problem with XML is that you have to know what you are doing right now..< bg >. He is right. However, I would submit that it is not a problem with XML per se. Rather, it is a problem with the implementation. Perhaps I am splitting hairs here, being too semantical. I am not sure I care since in the end, there are issues with people being able to implement the technology.
Not really. Comparing understanding XML to understanding COM is like comparing apples and oranges. XML is very high level, basically a text protocol. If you sit down and read an intro chapter in an XML book you can put that to use right then and there. COM is a system level architecture and you have to really understand how it works or else you'll not use it properly. You have to know about threading models, about marshalling about scope and ref counting etc. all the while not getting the control in high level languages to change the way it
works.
XML can be easy or it can be hard. I've always proposed that the core of XML is childishly simple, and I've been using only that very basic subset without digging into more advanced XML related technologies like XSLT, schemas etc. They have their use and are good for a number of things but they're not required. ANd even those are comparitively easy to implement and work with, giving only a little bit of ramp up.
>On one hand, I like the idea of removing uneccessary complexity. i.e., afford developers to time to concentrate on the problem instead of robbing the developers of time because they have to struggle with implementing technology. Technology is supposed to be the great enabler, not the time robber.
Well, you and I both know Microsoft doesn't give a shit about that. Otherwise we wouldn't have been shifting back and forth with technologies so much over the last 5 years. Microsoft wants to sell product and the best way for them to do that is have flashy features that demo well. Luckily this time around they're realizing that they need to address the enterprise features more heavily if they want to play with the big boys that dominate B2B etc.
I've been hanging out in some generic XML/SOAP etc. newsgroups and you'd be surprised how few people in these circles are using Microsoft tools. It's by no means a done deal that MS will dominate with .Net and VS.
>The issue I have right now with .Net is the safety net. The question is "Does a safety net exist?" If you buy into it, is it a one-way onramp? Does it constitute a destination with no return. I like having options. COM provides options. I can get into it as deep as I want. .Net is forcing folks to buy into the concept 110%. I beleive being on the cutting edge when it makes sense. I don't see how being on the bleeding edge here makes good business sense. I say this in light of your comment - you can do just about all of it today. I for one am going to let others take the big risk. I will be watching and evaluating. But for sure, I am not going to make huge investments until the dust settles. I see no gain by diving head-first now as opposed to gradually phasing in over a one year period.
That's true with any new technology. You can't know beforehand whether it'll work exactly as advertised or not. You'll have to wait and see.
>Simple is best - that is my mantra...
I agree. I'm not sure that .Net fits that mantra though. A lot of things are getting harder rather than easier in terms of how you write code. It's that whole Java mind set of revving through levels and levels of framework libraries with funky interfaces that were dreamed up by CS eggheads that don't build apps in the real world <s>...
Don't get me wrong - I have my reservations, but I do believe that Microsoft doesn't have a lot of choice and they're taking a bold path. If it works out and they deliver on the promise I think we will all be better off! But it will be painful to get there I can guarantee that even if everything works out flawlessly. The learning curve will be steep...
For me, I'm playing with it mainly to understand what we're talking about. You really can't judge any technology until you use it to build soemthing. So I'm not rushing out to re-write all of my WC apps to use .Net for example.
