[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster-devel] Re: [xmlblaster] Bugging me.
>Yes CORBA is the best tested protocol with xmlBlaster
>and it seems to be very stable and very high performing - i never had
>any problems with it concerning reliable communication.
Me either. Though I think a TAOist and an ACEkateer more than anything.
>The xmlBlaster SOCKET protocol is very simple and allows
>tunneling firewalls and with some tricks even proxies.
>It is not very mature, but remaining bugs will quickly disappear
Great! I shall read about it.
The number two reason for xmlBlaster for me is the multiple choice of
access, this is a superbly great, compelling feature. And you have some very
good points. Why would you start trying to wrap your head around the ins and
outs of IIOP/CORBA and its hybrids just to get the features of xmlBlaster,
when you will have trouble with fw, http proxies, socks etc anyway when I
could use any of the other means with which I'm familiar and support my
If your catering for socks etc, then this is a big plus. I hate socks.
All my point is I have already got ACE/TAO, these also are amazingly cool
tools. Make it easy for me to use it by a clear de-coupling of the
underlying protocol and user api. Given a choice I would rather have the
benefit of using TAO with any distributed application, but I'm not about to
try and tunnell through socks servers. So in this use case I would be
looking at the protocol you mention. My work doesnt yet involve having to do
To date I have been able to tunnel GIOP in HTTP using Bi-GIOP. I should like
to see Bi-GIOP support in xmlBlaster perhaps this something I could
investigate in time?
>as it is very simple.
>Also the performance needs to be tuned, as i expect it should
>by possible to outperform CORBA with our SOCKET in future.
Though is not CORBA your trying to outperform, it would be the
implementations your using, but I know what you mean. I am also toying with
trying to put GIOP through SMTP on port 25.One of the sys admins at work
recommended this on the basis that most ISP routers give a higher priority
to email. Believe it or not this is relativly easy with TAO. So the speed
test comparison might be interesting on long distances requiring a few hops
;-);-);-) It might be interesting, no socks etc (I think?)
>Yes, great tools for C++.
>But unfortunately it is a big beast and not very slim any more.
>Binding xmlBlaster to ACE i would like to avoid as we force
>all C++ users on ACE as well.
>Our C++ client should be tiny and portable.
>If users add ACE to our C++ code it should be there decision and
>not enforced by us.
You've right there, so you can see why I wouldnt want to add another socket
just my two Cents as well, I hope not to have offended anyone, I was so
hoping to make a good impression.