From activemq-dev-return-213-apmail-geronimo-activemq-dev-archive=geronimo.apache.org@geronimo.apache.org Mon Mar 06 15:08:04 2006 Return-Path: Delivered-To: apmail-geronimo-activemq-dev-archive@www.apache.org Received: (qmail 56972 invoked from network); 6 Mar 2006 15:08:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Mar 2006 15:08:03 -0000 Received: (qmail 69640 invoked by uid 500); 6 Mar 2006 15:08:49 -0000 Delivered-To: apmail-geronimo-activemq-dev-archive@geronimo.apache.org Received: (qmail 69614 invoked by uid 500); 6 Mar 2006 15:08:48 -0000 Mailing-List: contact activemq-dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: activemq-dev@geronimo.apache.org Delivered-To: mailing list activemq-dev@geronimo.apache.org Received: (qmail 69605 invoked by uid 99); 6 Mar 2006 15:08:48 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Mar 2006 07:08:48 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [199.105.164.5] (HELO smtpmail2.sensis.com) (199.105.164.5) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Mar 2006 07:08:47 -0800 Received: from dimstar2.ats.sensis.com ([172.21.1.6]) by smtpmail2.sensis.com with esmtp (Exim 4.50) id 1FGHJz-0007Qu-7G for activemq-dev@geronimo.apache.org; Mon, 06 Mar 2006 10:08:27 -0500 Received: from corpatsmail1.ats.sensis.com ([172.21.1.88] helo=corpatsmail1.corp.sensis.com) by dimstar2.ats.sensis.com with esmtp (Exim 4.50) id 1FGHJp-0003pk-L9 for activemq-dev@geronimo.apache.org; Mon, 06 Mar 2006 10:08:17 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: AMQ C#/C++ client refactoring suggestion Date: Mon, 6 Mar 2006 10:08:17 -0500 Message-ID: <7743F17344E95A4CA78A3E53A7AF496B0B673B@corpatsmail1.corp.sensis.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AMQ C#/C++ client refactoring suggestion Thread-Index: AcZBFjWCuTOy9jrmRnGUxRvxbE2vBwAA3bIwAAEwEiAAAVsQ8AACVc7QAACWnZA= From: "Mittler, Nathan" To: X-Sensis-MailScanner-Information: Scanned at Sensis Corporation by MailScanner X-Sensis-MailScanner: Found to be clean X-Sensis-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-1.8, required 5, autolearn=not spam, ALL_TRUSTED -1.80) X-Sensis-MailScanner-From: nathan.mittler@sensis.com X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Thanks, Mats - I'll work on getting it compiling on linux and share my = findings. Regards, Nate -----Original Message----- From: Mats Forsl=F6f [mailto:Mats.Forslof@portwise.com]=20 Sent: Monday, March 06, 2006 10:02 AM To: activemq-dev@geronimo.apache.org 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:nathan.mittler@sensis.com]=20 Sent: den 6 mars 2006 15:23 To: activemq-dev@geronimo.apache.org 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=F6f [mailto:Mats.Forslof@portwise.com] Sent: Monday, March 06, 2006 8:09 AM To: activemq-dev@geronimo.apache.org 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:nathan.mittler@sensis.com] Sent: den 6 mars 2006 13:52 To: activemq-dev@geronimo.apache.org 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=F6f [mailto:Mats.Forslof@portwise.com] Sent: Monday, March 06, 2006 7:05 AM To: activemq-dev@geronimo.apache.org 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