>Just wanted to bring up the other side of calling VFP components that you guys don't talk about too much: web services. If you expose your VFP components as web services then the CLR will never treat them as COM components. You have the web server where the component is called sending out XML and responding to an http method call. The CLR will consume and process XML and not talk to COM. Again, we have no complete data on performance in that scenario but we believe it will be a key way for VFP developers to expose components in .NET apps.
>

Ricardo,

There's an interesting implication here if I read you correctly - with the new XMLToCursor and CursorToXML capabilities, it would seem that we can hop right in and play, with the XML actually surfacing our interface for us - I'd originally thought in terms of a BizTalk environment for this, but in fact it's providing a really simple mechanism to let us surface a complex interface without the need to build individual custom COM components - a couple of classes that can surface and sink XML streams, and as long as we don't need to subclass the VFP wrappers internally using a CLR language, we can develop VFP components and use them inside .NET modularly. As long as CLR clients don't need to directly modify the internal logic of a VFP-written web service, we can hop in and out pretty freely.

A couple of questions arise from this, though. The biggest concern to me is that, if an XML stream is used to 'publish' our interface, how exactly do we inform .NET of changes to the interface? Will there be a mechanism to publish an XML interface document, similar in concept to what we do now in publishing a typelib, so that we can let other, non-VFP-aware things query the capabilities of our interface? I can think of several ways to do this, including a common XML stream addressed in a similar fashion to IUnknown in COM, but is there a better mechanism in the .NET philosophy? This approach is ideal for an environment like BizTalk - it's clear that we'll be able to write components for BizTalk using VFP, a very good think from my POV. How do we convey our current interface expressed in an XML stream to the .NET environment? I'm aware that we can publish a COM typelib to .NET - is there something similar to express XML interfaces?

Secondly, will there be a way to fire up a VFP component, have it run to completion, and then retain the VFP runtime environment (not so much the state as the runtime engine itself, as IL would offer) between instances of VFP services, where for some period in the life of the .NET application, there may not be anything crying for VFP's runtime to be retained in the working set? I see this as an issue, since VFP's engine is not necessarily svelte and trim - it's big, and imposing, and sucks up RAM with very little consideration of others playing in the sandbox with it - I'm thinking in terms of the less than optimal behavior I've seen with VFP running with it's default best guess for how to allocate RAM - it can get ugly very quickly if you don't use SYS(3050), especially if you tend to overallocate swap file space (I confess, I tend to add swap files to each physical drive on NT and 2K boxes, and rarely trim back the inevitable overallocation.) VFP then uses the virtual RAM address space size, not the physical RAM size, to guesstimate how much it should snatch up and squirrel away, in case it gets hungry a little later. The result is heavy swap file activity, in extreme cases with little UI activity, VFP can cause the OS to thrash out. Will we see some better protection from our own misconfigurations in VFP7 (hint, hint, beg, beg)?

Ed