Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of rob.j.godfrey@gmail.com
 designates 209.85.128.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52567847.6020406@redhat.com>
References: <525574AE.6050008@redhat.com>
	<CACsaS946uJZsYTPQoY+p6XnS_dVyt7zPewbjchTvJ9Ys7g03vQ@mail.gmail.com>
	<52558D29.8010108@redhat.com>
	<CACsaS94Z2ehawK24tVoFFnN2PpYuBK3EgdYC6JnSRUCr+X3h1g@mail.gmail.com>
	<52567847.6020406@redhat.com>
Date: Thu, 10 Oct 2013 11:58:29 +0200
Message-ID: 
 <CACsaS97Dve0SHGFb3eb1GCBNJwzqHP+w-GwRkrr15wFoCdx1Xg@mail.gmail.com>
Subject: Re: Qpid Dispatch Router component
From: Rob Godfrey <rob.j.godfrey@gmail.com>
To: "users@qpid.apache.org" <users@qpid.apache.org>
Content-Type: multipart/alternative; boundary=047d7b4721fe31210a04e8600b75

--047d7b4721fe31210a04e8600b75
Content-Type: text/plain; charset=ISO-8859-1

On 10 October 2013 11:49, Gordon Sim <gsim@redhat.com> wrote:

> On 10/10/2013 09:38 AM, Rob Godfrey wrote:
>
>> My main concern is that I believe that Qpid should be primarily directed
>> at
>> implementing AMQP standards, and building resuable toolkits and components
>> that fit into any AMQP network.  I'd be very concerned if we were
>> inventing
>> alternative management protocols, or building components that only
>> interoperated with other Qpid tools.
>>
>> So, personally I'd like to see statement around components saying that
>> they
>> will be fully implementing emerging AMQP Management, AMQP addressing, etc.
>> standards, and that we as a project then ensure we stick to these goals.
>>
>
> Interoperability with other AMQP compliant components both in and out of
> Qpid and Apache is certainly key. That is what AMQP is all about and what
> Qpid should be about.
>
> Faithful implementation of the existing AMQP specification is clearly a
> requirement as that is central to the charter of the project. Where any
> auxiliary or emerging specifications are adopted by a component, whether
> they are AMQP related or not, they should be compliant with that.
>
> However, having a general policy where all Qpid components are required to
> implement whatever 'emerging standards' come out of the OASIS AMQP TCs is
> not something I am comfortable with.
>

Saying that all Qpid components implement all emerging standards is clearly
not what I am saying, because not all standards are appropriate for all
components.  However I think the point of Qpid (vs. any other messaging
implementation at Apache or elsewhere) is to implement the AMQP
specification.  I'd generally question why work was being carried out in
Qpid (as opposed to elsewhere) if the work is not based on existing or
emerging AMQP standards.


>
> The Qpid community as a whole needs to have a say in how future features
> will work through an open, collaborative process (open to _anyone_, even
> those primarily involved with other AMQP related projects or products).
>
>
i completely agree.


> Personally I think this would be better for AMQP as well. Allowing and
> encouraging the emergence of grass-roots driven, de-facto 'standards'
> developed in and between open, collaborative and transparent communities
> and backed up by proven interoperable implementations, which can then form
> the basis for official de-jure standardisation.
>
>
Possibly, but I think that any such efforts at de-facto standardisation
must first reach out to other AMQP implementers and ensure there is a broad
agreement on direction.  If the Qpid project can be a vehicle for doing
this, then great - however currently that is not how Qpid is operating and
I would be very concerned at us trying to claim any sort of work done
within Qpid as a "de-facto" standard.  Where there is qork going on in AMQP
then we as the Qpid community should be ensuring that we feed back to that
and raise questions/objections as necessary (whether we are part of the
OASIS group or not - feedback from the public is possible).

-- Rob

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

--047d7b4721fe31210a04e8600b75--