Great stuff Mats! BTW as a background; tight v loose is one of those trade offs; loose is simpler to code and may use less CPU whereas tight uses the minimum possible network bandwidth. Depending on your use case loose could actually be the best choice - but its certainly the easiest to implement - so there's no real reason why non-Java clients need to worry too much about supporting it.
James On 3/16/06, Mats Forslöf <[EMAIL PROTECTED]> wrote: > Hi Hiram > > Thanks for the update. We have already selected the loose encoding as the > default encoding in the C++ client, it's good to see that we have selected > the same. The tight encoding is deferred to a future release since it is a > bit more complicated and we wanted something up and running. We're just > finished a architectural re-design in the C++ client that makes a lot less > code to maintain and a bit easy to add other protocols (see previous posts > regarding C++ refactoring suggestion). > > Will get back soon with a new patch udpate including updated groovy scripts. > > Regards, > Mats > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino > Sent: den 16 mars 2006 13:46 > To: activemq-dev@geronimo.apache.org > Subject: Re: OpenWire tight/loose encoding > > Hi Mats! > > On 3/16/06, Mats Forslöf <[EMAIL PROTECTED]> wrote: > > Hi, > > > > We need some additional information on the OpenWire protocol to wrap up our > > work on the C++ AMQ client. > > > > 1. To use loose encoding what do we have to do, is it simply to set the > > tight encoding attribute to false on the OpenWireFormat package and then > > send each package attributes one after each other? > > > > OpenWire should always start up in loose encoding mode, in version 1 of the > protocol, with all options off by default. This ensures backward > compatibitlity since future clients will beforced to be backward compatible > to even start talking. The clients then exchange a WireFormatInfo which > contains information about the highest version of the protocol and requested > protocol options that should be turned on. After that exchange both sides > can upgrade the version and options to a set that is compatible between the 2 > ends. > > > 2. What determines the order of the attributes on each package? The order > > now seems to be determined by the groovy scripts. > > They are in the order that they were defined in the orifinal Java command > classes. The groovy script just preserves the order. > > > > > 3. What about the order of the boolean flags used in tight encoding, what > > does each position stand for? > > > > The bits in the BooleanStream are also serialized in the same order. > > > I must ask you of some documentation on this because we cannot verify that > > our code is correct otherwise. > > > > Any time! I guess we need to update the C++ guy to support loose encoding > since that is now the minimum requirement. At least it's much simpler to > implement. Should I work on that or have you guys allready have that covered? > > Regards, > Hiram > > > Please help! > > > > Regards, > > Mats Forslöf > > > > > -- > Regards, > Hiram > -- James ------- http://radio.weblogs.com/0112098/
