On 09/16/2011 07:08 PM, Fraser Adams wrote:
Thanks for your support in this Gordon. I really do hope that there's an
elegant way to make interoperability the default position. Sorry if I
seem to be a broken record on this subject :-)
Not at all, taking the time to keep making that point is appreciated
even if we haven't quite kept pace with the feedback!
Is there any way that I can force the address string in C++/perl to be
treated as Unicode in
Receiver receiver = session.createReceiver(address);
I had a look at the jira you raised, so I guess that the answer to the
above then is no. Looks pretty down in the guts of Address string
parsing if it's being treated as a binary. I suspect I might be getting
away with it by the use of qpid::client in my organisation, perhaps I'll
have to back off my pressuring to move to qpid::messaging for now -
that's a real shame.
The only way to do this would be to directly manipulate the Address
object and not rely on the parsing of the stringified form at least for
those arguments.
On the subject of Address string parsing we spoke a little while about
maximum queue sizes and the miscellany of uint32, int32 etc. (and
Integer in the Java AddressParser) that have caused it to be difficult
to consistently have queue sizes larger than between 2GB or 4GB
depending on language and where queues are created. I know 0.12 has
fixed a lot of the broker side issues but the issue still exists in the
Java AddressParser, do you know what the position is for the C++ and
Python AddressParsers.
In python I don't believe there is an issue as it does not have the
concept of different types of integer based on their size in memory. In
c++ the values will be converted to int64 if possible. That does
restrict the size a little over a uint64, but certainly it is not as big
an issue as using a int/uint32.
We probably need to enhance the syntax to allow specific constructors or
descriptors to be used to control the exact types (e.g. my_value =
uint64(11) or my_value = 11LL etc).
Yes, I agree it is vital. I apologise for the frustration. I really
appreciate all your contributions on the list and certainly don't want
to drive you nuts! :-)
No need to apologise, life would be boring if everything was easy :-D I
wish I'd tried more of this sooner, it was looking into Jiri's problem
that prompted me to check this out.
Thanks again for your support and kind words about my contributions.
*hopefully* I'll be in a position to make a proper contribution over the
next few weeks. My Java implementation of the QMF2 API is coming along
nicely, the core features are done and I'm at the stage of finishing off
some of the "shinier" features such as Query subscriptions. I'd hoped to
have it finished by now, but I only get a chance to do development at
weekends and I've had a load going on over the last few weeks.
Look forward to it!
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
