qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: Decoupled qpid marshallers...
Date Mon, 16 Oct 2006 20:48:06 GMT

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 
> <mailto:hiram@hiramchirino.com>> wrote:
>
>     On 10/16/06, Carl Trieloff <cctrieloff@redhat.com
>     <mailto: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
>     <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