Mats, I've made quite a few fixes and almost have the code building clean on linux. The remaining issues involve the autogenerated code in the command/marshal directories, as well as the use of the smart pointers (p.hpp). The main smart pointer issue seems to be in the area of dynamically casting the pointer type to a derived type. If you're interested in seeing what I've done so far, I can post the code to a jira issue, otherwise I'll just keep working on the issues.
Regards, Nate On 3/6/06, Mittler, Nathan <[EMAIL PROTECTED]> wrote: > > Thanks, Mats - I'll work on getting it compiling on linux and share my > findings. > > Regards, > Nate > > -----Original Message----- > From: Mats Forslöf [mailto:[EMAIL PROTECTED] ] > Sent: Monday, March 06, 2006 10:02 AM > To: [email protected] > Subject: RE: AMQ C#/C++ client refactoring suggestion > > > Yes, both the command and marshalling code is auto generated so the > marshalling part must be moved into the command generation if we make the > change. > > We're using Windoze for development at the moment but the code are > prepared for *nix platforms. However we havn't had an opportunity yet to > test it on those platforms, it should require only minor tweaks to make it > compile though. Note however that the code is incomplete for functional > tests at the moment but it should compile. If you can help out with this it > would be great. Also, you need the Apache Portable Runtime 1.22 library to > make it compile. > > Regards, > Mats > > > -----Original Message----- > From: Mittler, Nathan [mailto:[EMAIL PROTECTED] > Sent: den 6 mars 2006 15:23 > To: [email protected] > Subject: RE: AMQ C#/C++ client refactoring suggestion > > I'm still coming up to speed on the C#/C++ client so I'm not prepared just > yet to offer suggestions on architecture (at least, probably nothing > terribly worthwhile). At the surface, what you're proposing makes > sense. The one question I have is: how does this affect code > generation? Are we currently auto generating both the marshalling and > command code? If so, it seems like consolidating would make the set of > groovy scripts smaller, which would be a good thing. > > BTW, I've been having trouble compiling the openwire-cpp code. I'm on > Linux with gcc 4.0.0. Have you been able to get the code compiling? > > Thanks, > Nate > > -----Original Message----- > From: Mats Forslöf [mailto:[EMAIL PROTECTED] > Sent: Monday, March 06, 2006 8:09 AM > To: [email protected] > Subject: RE: AMQ C#/C++ client refactoring suggestion > > 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 >
