Hi Nate, Thanks, that is an excellent suggestion, using a generic ProtocolFormat would do the trick. What do think otherwise, any other suggestions on how we better could prepare for the upcoming merge!?
Regards, Mats -----Original Message----- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: den 6 mars 2006 13:52 To: [email protected] Subject: RE: AMQ C#/C++ client refactoring suggestion Hi Mats, One thing to keep in mind is that we're going to start merging our efforts in the future (at least on the C++ side). I believe that means (please correct me if I'm wrong) that what is currently the openwire c++ client will eventually be extended to support other protocols (such as Stomp). If that's the case, adding protocol-specific marshalling methods to the Commands may get hairy. Perhaps rather than the marshal/unmarshall methods taking an OpenWireFormat object, they could take a more generic type, such as a ProtocolFormat, for example? This way, the Command interface could be reused across protocols and the higher-level code could eventually be reworked such that it doesn't care about which protocol it's using. Regards, Nate -----Original Message----- From: Mats Forslöf [mailto:[EMAIL PROTECTED] Sent: Monday, March 06, 2006 7:05 AM To: [email protected] Subject: AMQ C#/C++ client refactoring suggestion The marshalling is currently done by a set of stand-alone objects inherited from BaseDataStreamMarshaller or BaseCommandMarshaller. An alternative design would be to let each command itself be marshall aware, that is, have them implement a marshalling interface that has two methods; marshal and unmarshal. One of the parameters to those methods would be OpenWireFormat, the command calls marshall/unmarshall on the OpenWireFormat object for each command attribute. OpenWireFormat then performs the actual marshalling by a helper class called DataStreamMarshaller and depending on what the OpenWireFormat attribute "tightEncoding" is set to OpenWireFormat calls either tight or loose marshalling. The benefit of this would be less code and the control of tight/loose marshalling is done in one place. Please let me know what you think, I may have missed something that makes this unsuitable. Regards, Mats
