>THe biggest problem IMHO is not so much the disk usage but the distribution issue - most software is coming off the Web these days via download and the .NET framework is a 30 meg download.
>

And then the subsequent install issue, where there's a need to manage several versions of the CLR in the local machine environment. One thing everyone seems to miss is that the CLR is inherently unmanaged code, and is going to be dependent on more traditional installation issues; platforms that pre-date Win2K and side-by-side are IMO dead meat because of the need to resolve exactly which version of the CLR to use when a program compiled into CLR's IL is being executed, perhaps from the context of another version of the CLR. I haven't studiesd enough about the internal storage of WSDL to determine whether there's enough intelligence in the package to resolve which CLR to use; if not, DLL Hell is back with a vengence. And then we have the issue of the inevitable updates to CLR; again which of several CLRs to apply to becomes an issue.

The Chinese have a curse "May you live in interesting times" and every developer on the MS world today is looking at a very interesting future.

>>At some point, there's going to be a realization that there are flaws in the web services model of computing where behaviors must cross the web service interface; the contract embedded in XML will need to extend to data as expressions of process intepretable in a common cross-platform engine, a la the UCSD p-code initiative of the 1980s, or more recently, the myth of cross-platform Java, which while stated as "Write once, run everywhere" is far closer to "Write once and debug everywhere".
>
>Huh??? What does this mean? How does this relate to this topic?
>

This has to do with my postulate that web services will want to be able to transport behavior across the tier boundary, and the contract in XML regarding data types is not at present capable of transmitting the 'natural' common p-code of IL for client-side execution in the client's CLR is not now strong enough to do this. It's wild-eyed speculation that web services may ultimately construct and deliver custom client-side objects by carrying back packages of IL in XML streams for the client to mung. There are lots of ways of doing it, and the hypothesis may be inherently flawed by the definition of what is deliverable by a web service as it exists today; I haven't done as much reading on the topic as I should before spouting theory. I'm not convinced that web services will be ultimately successful without the ability to deliver client-side behaviors, and further speculation that we are entering a world where the CLR is touted as a universal virtual machine seems as flawed as the current implementation of the Java VM.

>
>>I don't see either as native language or development platforms; certainly, both have an internal script language, usable to either modify internal behavior through the creation of internally-interpreted functions, but there's no capability other than as a server and consumer of other's servces really present in either; they are ideal interface exposure objects, but lack the ability to host the myriad decision processes outside of their rather limited world-view.
>
>They won't need to because the CLR languages engines will allow exposure of everything via XML. SQL Server already does this in a limited way, I supect Office's future scripting engine and objects will do the same. Microsoft won't care that it only serves other Microsoft products I suspect especially in hte Office world.
>
>That wasn't really my point - it sounded like John was saying that these products would be re-written in a .Net language. I think what he was alluding to really was the scripting languages using CLR code, which is probably a good idea for consistency. T-SQL is one of the ugliest wanna-be languages around <g>...

OIC; I had thought that he alluded to the server engine being a set of CLR components. I think that a .Net language is going to suffer from the syntactic flaws that a '.Net' VFP would suffer from, in that the internal language modelling the world to be manipulated isn't reflected well by the syntax underlying the CLR; there's a need to build a rich set of concepts that will be relatively expensive to implement in IL. I don't see a benefit to moving these products to the managed code arena, unless you and John postulate that SQL Server and Office will run on all CLR client platforms rather than just Windows platforms; there's something to be said for unmanaged code for efficiency and tight integration with the platform. Lots of things are going to remain as unmanaged code, and these two products sit at or near the top of my list of things that might stay so.

Never mind; it's a natural side-effect from too much medication (tore the &*$#% hernia again, to be fixed Monday) and unwinding from being academic on UT. If I've confused the issues, I apologize, otherwise, I'm going to munch another Vicodin and go back to bed shortly...