[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.Not yet, but if you create one we could add it to the distribution.
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.
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.
Yes, you need a client side callback server.
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.
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
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.