Mailing-List: contact activemq-dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AMQ C#/C++ client refactoring suggestion
Date: Fri, 10 Mar 2006 17:06:09 +0100
Message-ID: 
 <221951ED658AA34D935E2B5FB6934920D2B78A@stosrv-exchange.portwise.com>
Thread-Topic: AMQ C#/C++ client refactoring suggestion
Thread-Index: AcZBio2jWYWceLEvRpqfE4/spYvviABMRLMQAAEJQ/AAArRt0AABqJXwAGJ8UoA=
From: "David Fahlander" <David.Fahlander@portwise.com>
To: <activemq-dev@geronimo.apache.org>

F.Y.I

I'm currently merging Nathan's patch with what Mats and I have been =
doing. If anyone is doing a lot of coding based on the checked in =
openwire-cpp, please let us know. None of us has contributorship right =
now so we have to do a little manual merging... When the merge is =
finished, I'll post it to Jira in hope of getting it checked in.

David

-----Original Message-----
From: Mittler, Nathan [mailto:nathan.mittler@sensis.com]=20
Sent: den 8 mars 2006 17:59
To: activemq-dev@geronimo.apache.org
Subject: RE: AMQ C#/C++ client refactoring suggestion

Ok, I've created a jira issue and attached my code.

http://jira.activemq.org/jira/browse/AMQ-620

I've put modified versions of the groovy scripts at the root dir.  They =
still need a few changes, such as the use of undefined classes (e.g. =
Object).

Let me know how the merge goes.

Regards,
Nate

-----Original Message-----
From: David Fahlander [mailto:David.Fahlander@portwise.com]=20
Sent: Wednesday, March 08, 2006 11:18 AM
To: activemq-dev@geronimo.apache.org
Subject: RE: AMQ C#/C++ client refactoring suggestion

Don't think we have a jira issue, but I'm not sure. I'm a little new in =
the project and Mats is ill but will hopefully be back soon to help me =
into the project routines... :-/  So maybe it's best if you open a new =
issue...
/David

-----Original Message-----
From: Mittler, Nathan [mailto:nathan.mittler@sensis.com]=20
Sent: den 8 mars 2006 15:57
To: activemq-dev@geronimo.apache.org
Subject: RE: AMQ C#/C++ client refactoring suggestion

I have noted the virtual destructor problems as well and have added the =
virtual destructor to (I believe) all the classes.  I'll post what I've =
done so you can start merging it in with your code.  Do you have an open =
jira issue that I could post to? ... I'd hate to open a new issue for =
every posting.

Nate

-----Original Message-----
From: David Fahlander [mailto:David.Fahlander@portwise.com]=20
Sent: Wednesday, March 08, 2006 9:34 AM
To: activemq-dev@geronimo.apache.org
Subject: RE: AMQ C#/C++ client refactoring suggestion

It's nice to hear that it was easy to port. Your work is of great =
interest for us. We are currently working on updating the code to =
correspond to the latest C# version. Please let us know your changes. =
There is also another issue, which is that all the interfaces lacks of a =
virtual destructor (easily fixed by just adding such on each interface =
(struct)).

Mats and I will soon send a patch with our updates as well.

David


-----Original Message-----
From: Nathan Mittler [mailto:nathan.mittler@gmail.com]=20
Sent: den 7 mars 2006 02:58
To: activemq-dev@geronimo.apache.org
Subject: Re: AMQ C#/C++ client refactoring suggestion

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 <nathan.mittler@sensis.com> wrote:
>
> 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 ]
> 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=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
>