activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mittler, Nathan" <nathan.mitt...@sensis.com>
Subject RE: AMQ C#/C++ client refactoring suggestion
Date Mon, 06 Mar 2006 15:08:17 GMT
Thanks, Mats - I'll work on getting it compiling on linux and share my findings.

Regards,
Nate

-----Original Message-----
From: Mats Forslöf [mailto:Mats.Forslof@portwise.com] 
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] 
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öf [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öf [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

Mime
View raw message