qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Qpid Dispatch Router component
Date Thu, 10 Oct 2013 14:00:50 GMT
On 10/10/2013 12:09 PM, Rob Godfrey wrote:
> On 10 October 2013 12:46, Gordon Sim <gsim@redhat.com> wrote:
>> On 10/10/2013 10:58 AM, Rob Godfrey wrote:
>>> I think the point of Qpid (vs. any other messaging
>>> implementation at Apache or elsewhere) is to implement the AMQP
>>> specification.
>>
>> I have no disagreement when the AMQP specification is what is currently
>> published.
>>
>> My concern is where that is defined to be an expanding, all-encompassing
>> effort that ring fences whole areas of behaviour and sets itself up as the
>> only legitimate avenue for exploration.
>
> Do you believe that is what the OASIS TCs are doing?  If so in which areas?

The idea of a general policy that any Qpid component must support any 
emerging standard from those TCs in a particular area and cannot explore 
alternatives or anything that may overlap does feel very much like this.

I am not saying that is what you meant, merely expressing that I would 
not be comfortable with such a policy if it was.

>> Expanding beyond the current specification needs a more diverse source of
>> ideas and a more open, transparent and collaborative process.
>>
> While I agree that a more open process is most definitely desirable, I
> would argue that the OASIS TCs (sadly) currently have a much more diverse
> membership than Qpid committers.Also note that you do not need to be a
> member of OASIS to comment on work going on there.  If you (or anyone else)
> believe that the work going on in OASIS is misguided you should comment
> there [1], not here.

While involved at OASIS I did comment. However, I am not now seeking to 
reform the AMQP work at OASIS. Any such effort should indeed take place 
there and not here.

Neither am I trying to subvert it. I have no issue with you or anyone 
else working on projects within Qpid related to specifications you are 
progressing at OASIS, providing anyone else can join in and contribute 
ideas.

All I am saying is that I don't consider OASIS to have authority over 
what other work goes on in Qpid, again provided that work is done in an 
open and collaborative manner which listens to criticism of the approach.

Collaboration doesn't have to mean that everyone agrees on one point of 
view. A degree of exploration of alternatives is in my view healthy at 
this point provided we all conform to the underlying specification as 
published and strive to ensure the various voices in the community are 
heard and that whatever is produced serves the needs of those using it.

I myself will very happily contribute to, align with and support any 
effort that I see emerging with genuine widespread support from existing 
communities. If that is a spec from OASIS, great. If it's an idea from 
one of the other implementers, great. I want any additional standard to 
be adopted on merit not by fiat.

In the end I believe we want the same thing, we have the same goal of 
richer interoperability and I do firmly believe that while in theory we 
have different views on how best to achieve that we can collaborate 
effectively on the practical side of aiding AMQP adoption and on 
concrete issues we are as often as not likely to find a happy compromise.

Now, as to improving the process at Qpid and building a more diverse set 
of contributors, that I am very much interested in and this is the 
perfect place to discuss it. I would be eager to hear from anyone with 
ideas that could help.

> While I may not be entirely happy with the OASIS process, the value in AMQP
> is in standardisation.

The value is in practical interoperability and interchangeability.

Though I personally don't think OASIS is the best route to achieving 
that, I respect your view that it is. There should be room for both of 
us to help users reap the benefits that AMQP promised.

>  If Qpid can be a place where multiple parties can
> come together and work together then it may be a good place for de-facto
> standards to emerge.

I want to be really clear on this point as it comes up several times 
here and in previous mails.

I said that I believe the emergence of de-facto standards is something 
to be nurtured and encouraged. I think Qpid can have a part in that, but 
I think it can *only* be a part. It *must* involve other communities, 
projects and products. So I am certainly *not* suggesting that I believe 
that work at Qpid should be taken as a de-facto standard.

[...]
> Historically Qpid has not been seen as a neutral place.  For better or
> worse, there are a preponderance of committers from one organisation.  In
> order to counter perceptions of a lack of neutrality I think work has to be
> done to bring more people in before we try to sell ourselves as a neutral
> venue for emerging standards.

Again, just so there is no misunderstanding, I am *not* 'selling Qpid' 
as such a venue...

>  Until we can actually demonstrate that Qpid
> is such a place I think it is presumptuous of us to try to claim de-facto
> standards for our work.

...and I have made no such claim.

A de-facto standard is not something you can claim. It is something you 
prove by showing the different interoperable implementations.

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


Mime
View raw message