qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marnie McCormack" <marnie.mccorm...@googlemail.com>
Subject Re: Decoupled qpid marshallers...
Date Mon, 16 Oct 2006 20:59:52 GMT
I think it would be useful where the work touches on any major areas/changes
basic functionality.

At the very least, we should be making it clear that everything we work on
going forward should be JIRA'd so we have traceability for testing etc.

I'm aware that our JIRAs really only reflect the position with the Java
broker. We should have a set for all implementations.

I'd also be happy to see people getting acquainted with the Java code by
opting to work on some of the simpler tasks that we've put up there now. We
know that there will be more complex work coming as a result of AMQP
developments, so now is the time to get familiar with what we've got.

We do still need to address the issues around keeping in step with the
protocol work, but that's for another email :-)

Regards,
Marnie
On 10/16/06, Carl Trieloff <cctrieloff@redhat.com> wrote:
>
>
> Question - do we want  open JIRA's for work in progress? I though we only
> wanted to add new work
> /open issues to JIRA?
>
> Carl.
>
> Marnie McCormack wrote:
>
> Sounds like we need everyone to create JIRAs for all the tasks in progress
> to avoid disconnect, please ?
>
> I've noticed that there are commits going on that don't have matching
> JIRAs. This isn't ideal, particularly since we are going to need release
> notes in the near term which would ideally be autogenerated from JIRA.
>
> Seems like we need a little more visibility across the piece.
>
> Marnie
>
>
> On 10/16/06, Hiram Chirino <hiram@hiramchirino.com> wrote:
> >
> > On 10/16/06, Carl Trieloff <cctrieloff@redhat.com> wrote:
> > >
> > >
> > > Kim has been working on a new generator and updated framing which
> > should
> > > be in, in a
> > > few days. Might be worth waiting for that to eliminate rework. He has
> > > wiki page on it.
> >
> >
> >
> > waiting?? I'm done! lol!
> >
> > Carl.
> > >
> > > Hiram Chirino wrote:
> > > > Hi,
> > > >
> > > > I just wanted to let you guys know that as the first step for
> > ActiveMQ
> > > to
> > > > support the QPID protocol, I made a more decouple version of
> > marshaling
> > > > generators that qpid implemented.  You can find the work here:
> > > >
> > > > https://svn.apache.org/repos/asf/incubator/activemq/sandbox/qpid
> > > >
> > > > Major differences between it and the original qpid versions are that
> > > > (1) it does not depend on MINA, or any of the qpid internals
> > > > (including the
> > > > qpid exceptions).
> > > > (2) it follow the pattern of separating the command logic from the
> > > > marshalling logic.  This is a pattern that has proven useful in our
> > > > openwire
> > > > protocol.
> > > > (3) supports calling a visitor for faster/type safe command
> > processing
> > > > (4) command properties now have getters and setters for better
> > > > encapsulation
> > > > (5) all commands now inherit from Frame (simplifies and reduces
> > object
> > > > creation)
> > > >
> > > > Ideally It would be nice if qpid could maintain nicely decoupled
> > > > marshaling
> > > > package like this.  That way, ActiveMQ could just pick it up and use
> > it.
> > > > But it's not a big deal for us to maintain so if it's not picked up,
> >
> > > it's
> > > > not a big deal.
> > > >
> > > > The module also includes integration into activemq where we add
> > > > support for
> > > > a 'qpid' transport which understands the amqp protocol using the
> > > > above.  A
> > > > small Main that starts up an ActiveMQ transport proxy was used to
> > verify
> > > > that marshallers work.  The proxy unmarshalls to the command objects
> > > > and the
> > > > forwards which cases the same object to be remarshalled.
> > > >
> > > > Now that we can talk the talk.. it should not take long for ActiveMQ
> > to
> > > > directly support AMQP also.
> > > >
> > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message