>>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'm not sure exactly what you're looking for - binary object representations that include method signatures and the code that goes along with it?
>
>That would be folly and should definitely not happen as that would make WS totally non-cross platform... Web Services are a data transport and as such should transmit data structures, which is pretty much what the spec does.

We've long practiced the use of data driven behavior; essentially, the creation of a contract in which we agreed that we could exchange data to indicate the triggering of behavior. We now use the exchange of scripting language (eg T-SQL) in order to explicitly exchange behavior requests between client and server. To me, the extension of this to the exchange of behaviors between client and server through the passing of objects, in which behavior is exchanged through submission of a common p-code rather than the ASCII representation of script seems rather natural.

I understand the problem of exchange between two non-compatible platforms being unsupported at present; eg the problems passing ADO recordsets to a non-Wintel platform. If we're going to make all the sacrifices that managed code calls for, I don't see a strong argument in favor of exchange of a scipt language represented in ASCII, requiring yet another layer of emitter and interpreter, and the exchange of IL, at least between two managed code systems, given that both systems have identified themselves as being managed code platforms.

Both you and JVP talk in terms of moving the scripting language for SQL Server and Office to the CLR environment; if your intent to make the scripting language more consistent with the implementation of an existing scripting language that will compile directly to IL on the server side, which is going to involve implementation of a compiler or interpreter server-side that translates the language into CLR, calling into services implemented locally at the server, or that the client will pass IL to the server which is then executed directly by the server-side CLR?

We can reform the languages of T-SQL and VBA to be more consistent in behavior completely independent of the issue of a managed code emitter; in both cases, an interpreter is required server-side, and whether the interpreter creates IL or the interpreter calls methods and functions implemented in unmanaged code is immaterial. The idea behind implementing the language to play in the CLR is one of cross-platform compatibility for the execution environment; if the server platform is still implemented in unmanaged code, and doesn't benefit directly from transportability of the server to new environments, I don't see the advantage of making T-SQL a CLR player.

>
>Web Services will not completely replace binary protocols like DCOM and CORBA simply because those protocols will be faster for direct machine to machine communication in a controlled environment. System services still require this type of thing with performance that Web Services won't be able to touch and flexibility that is lower than what a Web server based interface can provide.
>

Agreed, and these will put limits on cross-platform compatibility, as they do today. The need to provide data in a more compressed format that XML is one issue. The need to exchange behaviors between server and client is another. What eludes me is where converting the scipting languages for the two servers, Office and SQL Server, fits other than in this arena.

>With some logic on the CLR's part it would be possible to automatically be able to map object to object assuming the same object exists client and server side, but for some dim witted reason Microsoft thinks this is not even worth considering as a built-in feature. I discussed this kind of thing with various Microsoft people and they either didn't get it, or it's not really possible to do.
>

We agree here; that's my premise for supposing the exchange of IL between client and server being the basis for what you and JVP suggest as compelling reasons for moving the scripting lanaguage into the CLR arena. Whether the contract between client and server is one of exchange of behaviors and data representations using the CLR model directly, or contracting to have a meaning applied to the scripted exchange, is what I'm missing. Without the ability to exchange managed code objects directly, what advantage do you see to moving the scripting language to the CLR, since there's still a huge issue of marshalling the object between client and server if the behavior exchanged must be reinterpreted on both sides for both behavior and property values.

>I think it's important to have a way to automate object mapping using the data structures travellign over the wire as the transport, but that's purely an optional feature that makes life easier. Given that a language doesn't have hte capability and tools to do this (and the CLR doesn't without a fair amount of code anyway), then you'd have to write manual data mapping code to reattach the data to the business logic on the client side.
>

Agreed.

>Microsoft does what MS does, right? It's all or nothing always - I think that their take for Web Services and remote connection for everything is not realistic for a number of situations. But that doesn't mean that the technology is flawed - it just means that it's overhyped to fit into places where it'll be better to use more traditional models of data access/management.
>

We differ, in that I see the inconsistency as a flaw in the design of Web Services (the lack of agreement on a contract for exchanging behavior), and you see it as a miscue in the marketing strategy. The result of the inconsistency is that Web Services will not directly benefit from the use of managed code in the implementation of scripting languages exchanged between client and server; we still need a scripting interpreter on each side that can receive script to direct behavior, and whether this interpreter emits IL to run under the CLR or provides its own runtime engine and the interpreter emits p-code that runs on it's own engine seems immaterial. The advantage of the scripting language being a CLR language is only a direct benefit for exchanges between two managed code environments.

Or am I missing something incredibly obvious here?

>>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.
>
>Well, I can see Office using CLR language constructs which is probably a close match to the way that things work already. But for Office that would also mean that these objects would have to be either native CLR code or else mapped to native CLR objects that access the underlying COM code. Which seems silly either way...
>
>Good point about the language issues. I hate Transact SQL though and getting a real language would be very nice inddeed. But how would you run a SQL Statement in that environment? Calling an object that does an execute? T-SQL like VFP has the advantage of not requiring strings but can put SQL directly into the code, which is much easier to code and get right than hairy strings that are concatenated together.
>

Yep, so strengthen the contract in XML so that we chan exchange behaviors seems a logical solution here. Getting T-SQL to be 'a real language' is separate from it's issue of being in the CLR; it requires that T-SQL implement a more acceptable and wide-ranging, consistent form, which is a separate issue from it playing in the CLR. After all, I hate COBOL with a passion, too, but COBOL is going to be available as a language emitting CLR; we can reform the T-SQL language (Which I agree is an abortion) without putting it in the managed code arena.

>It's like you said - things will be interesting for the near future as people figure out all the ugly things that we didn't hear about during the beta. I think deployment, security, performance and the whole garbage collection/no concrete destructors will give a lot of people serious headaches when it comes to building commercial grade applications.

You're preaching to the choir.

Please continue this - I'd really like to see where you perceive the flaw in my reasoning that implies that the reform of the scripting languages and their movement into the CLR are two entirely distinct issues.