BTW I made a slight change to OpenWire the other day, turning Command.commandId into an int rather than a short (so that we can reuse it as a reliability counter when using unreliable transports like UDP/multicast) - I hope it does't cause too many problems in the C/C++ code. I"ve patched the C# code but the C/C++ code still needs upgrading.
James On 3/17/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > Great! > > I can't wait to peek at the patch! > > Regards, > Hiram > > 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: [email protected] > > 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 > > > > > -- > Regards, > Hiram > -- James ------- http://radio.weblogs.com/0112098/
