qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: Java broker queue questions....
Date Tue, 12 Mar 2013 19:37:55 GMT
On Tue, Mar 12, 2013 at 2:02 PM, Rob Godfrey <rob.j.godfrey@gmail.com>wrote:

> On 12 March 2013 14:48, Rafael Schloming <rhs@alum.mit.edu> wrote:
> >> [.. snip ..]
> >
> > I largely agree with what you've said, however a few thoughts come to
> mind.
> >
> > First, because AMQP 1.0 is different and so much more general than
> previous
> > versions, I think the notion of a reference implementation of AMQP has
> > problems as a way of defining scope. Strictly speaking, AMQP 1.0 is a
> very
> > general purpose protocol that could be used by any network application
> (not
> > just message brokers), and therefore a reference implementation that
> makes
> > no choices beyond what is defined in the spec would be limited to a
> general
> > purpose protocol implementation like the protocol engine that Proton
> > provides.
> Indeed... Though I think one can go further than that and start
> defining what it is that is expected in a traditional "client" role.
> Making the power of AMQP 1.0 available through programming APIs which
> can be used by application programmers with only a superficial
> understanding of messaging seems to me to be within the scope of such
> a "reference implementation".  Where things do become fuzzier (at
> least until such things are "standardised" within the AMQP community)
> are components such as brokers, proxies, gateways, etc...
> My view here is that within Qpid we should always be looking to build
> things that only require AMQP in order to interoperate.  That is if we
> build something within Qpid that only works if it is communicating
> with something else within the Qpid suite, I think we are on the wrong
> track.  Such an interoperability gap can be bridged by ensuring that
> we push as much through the standardisation process as possible.
> >
> > There are, however, a whole host of intermediaries, (brokers, proxies,
> > gateways, etc) that form key infrastructure for building distributed
> > systems, and it would certainly be very handy to have good versions of
> > these that speak AMQP in a first class way. There is a slippery slope
> here
> > though since you could build an AMQP controlled networked toaster and
> > unlike the previous examples, that wouldn't necessarily fit in as part of
> > Qpid.
> >
> > Gven the above and the fact that not everyone necessarily knows what AMQP
> > is, I think we should be able to define what we are and where we are
> going
> > without so heavily referencing AMQP.
> >
> I disagree with any notion that our definition should not be heavily
> referencing AMQP.  I think there are really interesting things that
> can grow out of this work; and perhaps some of them may want to
> eventually spin off as separate projects which *use* AMQP/Qpid... but
> I think that Qpid should be about enabling interoperable AMQP
> networks.

I'm not saying we should build stuff that has nothing to do with AMQP
(rather the opposite), I'm just saying that your definition shouldn't
assume that everyone shares your understanding of AMQP 1.0, its
capabilities, and its differences from prior versions. Right now it does
and so could mean vastly different things to different people.

> > Finally, I've seen your view and similar views expressed a number of
> times
> > now. There appears to be strong consensus that there is a problem here,
> and
> > rough agreement on the nature of the problem, yet no concrete action ever
> > seems to arise despite several attempts (e.g. Justin's retrospective
> naming
> > changes and web site work). I don't mean to single you out or anything,
> but
> > I feel like there has been general apathy (myself included) on this front
> > when it comes to taking real action, so I have to ask: what do you
> suggest
> > we actually do to address the problem?
> >
> > FWIW, I think the retrospective naming is something small and concrete
> that
> > we could actually do about the problem, and it strikes me as better than
> > doing nothing, so I'd be in favor.
> >
> Frankly I think the retrospective re-naming causes as many issues as
> it solves.  I actually think the key for us is just to document what
> we have and where we are going and to make sure we publicise the
> latter.  Calling a component the "C++ broker" or the "Java Broker"
> doesn't seem to me to be substantially worse than giving it a random
> new name that no-one will actually remember :-)  As Fraser pointed out
> the two brokers are similar but by no means the same... so would they
> share a name or not?  I think if we eventually decide engage in a
> complete rewrite of one or both the brokers then I would support
> giving such a new broker a new name... but I don't really see that
> trying to reaname the existing artefacts is going to get us very far/

 I think "documenting what we have and where we are going" is too large,
amorphous, and difficult as a task to "just do." There have been several
attempts at this already and they don't seem to result in strong consensus.
I was hoping there might be some smaller and more concrete step we could
take that would be more likely to succeed.


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