On 2/24/06, Uwe C. Schroeder
In the end it's not a flaw in the design. The software package with close to 1.5 million lines of code runs just fine and did so for many years. The problem is that customers hire some homegrown MS Access programmers for whom anything remotely like network programming is a black box and expect them to be able to write a module for my system. It's pretty hard to explain deferred's to someone who thinks a socket is the power outlet where he plugs his vacuum in and a port is the thing where the ships go to. Guess who gets the blame when their employees can't handle it. Thus the idea to make that API a bit less "deferred". Yeah - I should tell them "hire decent programmers who have a clue"... Well, was worth a try - someone might have come up with something...
I came across this problem recently. I ended up using XML-RPC.NET for the VB side, and twsited's own XML-RPC server for my side. It took me about a week to realise that this was how to resolve my problem, rather than working out (in my case) how to make PB be COM-Compliant. It had the advantage that I just passed an interface file alogn to my VB programmer who could plug it into hsi system, and he got all his fancy syntax checkign and pop up values and all the rest. I did consider SOAP, but WSDL gave me a headache, and I will apparently have to cope with a VB6 project hooking up to my code in the near future, for which there is a COM-based XML-RPC library available. If it is something they're goign to be "hanging" on for a significant amount of time, you can, at the very least, offer them a UUID and a method that they can poll to see if the deferred has fired. Moof