>>>>Used to be, and still am, a big fan of delimited strings, but with parameter passing in an OO world, I think it's less clear than manipulating properties or using an object. But, maybe the self-describing format of XML is the way to go!
>>>
>>>There's a problem with XML; there's no pre-negotiated schema to pass processing instructions; (eg there's no pre-agreed p-code that I can use to pass a VB app the processing that goes on inside of a COM object or web service; as long as only data is being passed across by an object, there's no problem marshalling it with XML, but there are issue to at least negotiate in order to marshal behaviors.)
>>
>>Interesting. If I understand correctly, XML works fine for data transfer between caller and callee. However it will not suffice for the bridge object behavior you envision, because there are no standards for code transfer.
>>
>>Now, that really is an interesting thought. Howabout using VFP to generate managed code (once there's a pre-agreed p-code)? After all, it handles strings pretty well, I'm told.
>>
>
>As long as both side speak CLR, they're fine. If both sides have a VFP runtime engine present, you could pass VFP p-code (an FXP or the like) or could run something like CodeBlock to have a common execution engine. There are lots of possibilities; what it takes is a contract involving the meaning of the data passed between the two tiers.

I guess I'd always considered that programmatic interaction between physical tiers would always be through RPC. But, you're suggesting that one tier can send an XML package which actually contains the behavior it wants performed. That might have some interesting performance implications. And, that gives the possibility of creating and adding behavior on the fly from one tier to another tier, if needed.

Interesting...

Jay