[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster-devel] C# Clients

Tim Heilig wrote:
As I C# programmer who has used xmlBlaster for some time, I have a couple questions, plus a few thoughts about the current state of C# clients.

Right now it looks like there are 3 options, activex bridge, xmlrpc, and using dhtml with a hook in a webbrowser control.

Rather than reply to the various threads of each method, I wanted to compress the information into one thread.

general question:
Are there xsd's for the UpdateQos and UpdateKey? This would enable the microsoft tools to deserialize into objects. I'd prefer to deserialize into C# rather than hold onto com objects that have to be marshalled to the activex thread to make interface calls.
Not yet, but if you create one we could add it to the distribution.

I'm assuming that this requires server initiated connections. If this is the case, xmlrpc can't be used for C# clients that reside behind nat networks, correct? If there is an xmlrpc C# client that doesn't require the client to be running its own xmlrpc server, I'd love to hear about it.
Yes, you need a client side callback server.

This should be an easy thing to implement, but dhtml has a few inherent problems. There are a few traffic choke points because browsers deal with message overloading very poorly. This results in poor performance (relative to the other clients) in high traffic situations. Also if you are not able to load every pending message in the http transfer window, the client goes into a loop where it times out, reconnects, tries to load everything, times out, reconnects, etc.

As far as I can tell, the HelloWorld3.cs demo doesn't currently work. I made some changes to get it to work. Ideally I'd like serialized xml getting passed to the C# client, but when I tried to create an event that passed (string, byte[], string) or (string, string, string) with the content base64 encoded, I failed miserably. If someone who knows the activex bridge better would be willing to help in this endeavor I'd appreciate it. As it is now I have to do an InvokeMethod on the EventObject that gets passed to me to get serialized strings. Also, I added getKeyStr and getQosStr to the XmlScriptAccess interface. Obviously its possible to get the xml by invoking getKey() (or getQos()) followed by toXml() but I'd prefer to only marshal once rather than twice.
Your contribution with you changes would be welcome.

Some members of the mailing list are discussing to add a SOCKET protocol for C#
to overcome the performance/callback issues you mention above.
But i think they haven't yet implemented it.


Please correct any mistakes I made, or respond if you have any questions.