qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Java broker queue questions....
Date Tue, 12 Mar 2013 18:02:21 GMT
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.

> 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/

-- Rob

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message