You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2007/01/17 13:25:48 UTC
AMQP 0-9 support
Are we planning that our 0-9 branches will support both the core
protocol and the WIP additions? If so would we do that simultaneously
(i.e. a single broker could do both)?
Re: AMQP 0-9 support
Posted by Gordon Sim <gs...@redhat.com>.
Robert Godfrey wrote:
>>
>> Thats really just been me, and I accept I am being rather pedantic! To
>> again repeat what I tried previously to say, I am not at all against
>> adding to the protocol. I would however (where feasible) much prefer
>> that we didn't actually break it for simple scenarios. My view should be
>> taken purely as the opinion of one person though!
>
>
> I agree with you... I think my point of view is that the broker should not
> require the clients to be anything other than compliant with the AMQP spec.
> However we may choose to "enhance" the spec that the broker accepts in
> anticipation of such changes being adopted, as long as the changes do not
> prevent other clients from connecting.
>
> Further I think that when operating as an AMQP client, each of the client
> packages should be capable of communicating with any AMQP compliant broker
> (of the relevant version of the spec).
>
> However, we may choose to operate the client in a mode which requires our
> extension (and therefore our broker, and possibly the other endpoint to be
> an instance of our client). this is the case for JMS compliance.
>
> I think the problem is that at the moment the Java client package does not
> have a good, separate, AMQP API, and so the only mode to operate in is "JMS
> Compliance" and JMS compliance and AMQP compliance are (currently)
> incompatible.
>
> I would be a strong supporter of creating a distinct AMQP API for the Java
> client, which would be guaranteed to work against any AMQP broker, and
> to be
> able to communicate with any other flavour of AMQP client.
I'm in full agreement with you there. My original post was an attempt to
see whether we could, through only simple changes that did not break JMS
compliance, allow the java client in JMS mode to at least connect to any
AMQP broker and exchange messages providing any of the non-string
property types are avoided. i.e. a restricted use of the JMS mode until
another level of java client exists (or the protocol is updated for
standard JMS compliance).
Re: AMQP 0-9 support
Posted by Robert Godfrey <ro...@gmail.com>.
>
> Thats really just been me, and I accept I am being rather pedantic! To
> again repeat what I tried previously to say, I am not at all against
> adding to the protocol. I would however (where feasible) much prefer
> that we didn't actually break it for simple scenarios. My view should be
> taken purely as the opinion of one person though!
I agree with you... I think my point of view is that the broker should not
require the clients to be anything other than compliant with the AMQP spec.
However we may choose to "enhance" the spec that the broker accepts in
anticipation of such changes being adopted, as long as the changes do not
prevent other clients from connecting.
Further I think that when operating as an AMQP client, each of the client
packages should be capable of communicating with any AMQP compliant broker
(of the relevant version of the spec).
However, we may choose to operate the client in a mode which requires our
extension (and therefore our broker, and possibly the other endpoint to be
an instance of our client). this is the case for JMS compliance.
I think the problem is that at the moment the Java client package does not
have a good, separate, AMQP API, and so the only mode to operate in is "JMS
Compliance" and JMS compliance and AMQP compliance are (currently)
incompatible.
I would be a strong supporter of creating a distinct AMQP API for the Java
client, which would be guaranteed to work against any AMQP broker, and to be
able to communicate with any other flavour of AMQP client.
- Rob
Re: AMQP 0-9 support
Posted by Carl Trieloff <cc...@redhat.com>.
Excuse the top post...
These would be my two comments,
First, as we develop we will find things that need to be fixed or worked
in the spec. That is good and from my side I have no issue the qpid
project working them out. However when we do that we should raise it to
the list and make sure we take them back to working group. Once the
issue has been worked at the working group we should then revisit and
update as to how it is modified in the spec. I expect that we will have
back and forward for a few months yet as the spec develops. Maybe we can
create a separate section in JIRA for this so that we don't lose them.
Second item is: we need to make sure that we maintain interop between
all the impl within the qpid project.
On the item of spec compliance, I don't think we have claimed that yet.
I am not even convinced that M1 is compliant with 0.8. As we are
developing the project while the spec is being developed I would expect
that we would goal to be compliant on a future release once the codebase
and spec has stabilized. We might be able to do that for 0-10 if most of
the open items (for example JMS, type system, ...) get resolved and in.
So yes, I agree with the comment made in this thread, and to Gordon's
point we need a better way to keep track of these items.
Carl.
Gordon Sim wrote:
> Robert Godfrey wrote:
>> Are you saying we will not support those parts of 0-9 which are also
>> in 0-8
>> (i.e. Basic, File and Stream)?
>>
>> As far as I understand it, those are still in the spec although
>> marked as
>> likely to be replaced. If we are claiming spec compliance should we not
>> still support these classes for the moment?
>
> That would have been my understanding as well.
>
>> If spec compliance is not our
>> goal (i.e. we are really anticipating a later version of the spec where
>> these elements have been removed) we should be clear about that.
>
> I agree.
>
>> On other
>> threads we have been quite reluctant to get "ahead of the spec".
>
> Thats really just been me, and I accept I am being rather pedantic! To
> again repeat what I tried previously to say, I am not at all against
> adding to the protocol. I would however (where feasible) much prefer
> that we didn't actually break it for simple scenarios. My view should
> be taken purely as the opinion of one person though!
Re: AMQP 0-9 support
Posted by Gordon Sim <gs...@redhat.com>.
Robert Godfrey wrote:
> Are you saying we will not support those parts of 0-9 which are also in 0-8
> (i.e. Basic, File and Stream)?
>
> As far as I understand it, those are still in the spec although marked as
> likely to be replaced. If we are claiming spec compliance should we not
> still support these classes for the moment?
That would have been my understanding as well.
> If spec compliance is not our
> goal (i.e. we are really anticipating a later version of the spec where
> these elements have been removed) we should be clear about that.
I agree.
> On other
> threads we have been quite reluctant to get "ahead of the spec".
Thats really just been me, and I accept I am being rather pedantic! To
again repeat what I tried previously to say, I am not at all against
adding to the protocol. I would however (where feasible) much prefer
that we didn't actually break it for simple scenarios. My view should be
taken purely as the opinion of one person though!
Re: AMQP 0-9 support
Posted by Gordon Sim <gs...@redhat.com>.
Rafael Schloming wrote:
>
>
> Robert Godfrey wrote:
>> Are you saying we will not support those parts of 0-9 which are also
>> in 0-8
>> (i.e. Basic, File and Stream)?
>>
>> As far as I understand it, those are still in the spec although marked as
>> likely to be replaced. If we are claiming spec compliance should we not
>> still support these classes for the moment? If spec compliance is not
>> our
>> goal (i.e. we are really anticipating a later version of the spec where
>> these elements have been removed) we should be clear about that. On
>> other
>> threads we have been quite reluctant to get "ahead of the spec".
>
> Currently we don't actually support file and stream, just basic, so we
> won't really be in a different position with respect to spec compliance,
> we're just converting our basic support to message support.
The spec says that a broker MUST support the basic class but MAY support
the file or stream classes.
Re: AMQP 0-9 support
Posted by Robert Godfrey <ro...@gmail.com>.
>
>
> I agree it's worse now, but I suspect that our development will continue
> to lead the spec even past the 1.0 version, in which case we will need
> some kind of negotiation because we can't have all our clients and
> brokers advertising AMQP 1.0 during negotiation and then using project
> specific extensions.
I agree - once we get to 1-0 we *must* perform some protocol negotiation if
we intend to deviate from spec. I believe the rule is that once the
protocol gets to/beyond 1-0 is is encumbant upon brokers to support previous
versions of the protocol. Is there anyway in the spec to define negotiation
of implementation specific features... or shall we just use the client
properties (i.e. if you advertsie that you are a QPID client then we assume
you are capable of talking QPID AMQP)?
- Rob
Re: AMQP 0-9 support
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Godfrey wrote:
>>
>>
>> Currently we don't actually support file and stream, just basic, so we
>> won't really be in a different position with respect to spec compliance,
>> we're just converting our basic support to message support.
>
>
> Which is fine, but if we are working off the public spec then Basic is
> still
> current whereas Message is marked as Work In Progress. We have to be very
> clear that we are moving to virtual non-compliance with the published spec.
> We are doing this for good reasons (i.e. we are confident that the spec
> will
> move into conformance with QPID), but we will likely cease to be compatible
> with any non-QPID AMQP implementations.
Agreed
>
> Personally I don't have an issue with getting ahead of the spec, I think
>> we just need to be more careful about how we do it so that a) we don't
>> break interoperability between the different qpid implementations at the
>> very least, and b) so that we don't needlessly break compatibility with
>> the spec when it would be just as easy to extend the spec, e.g. by
>> choosing type codes for the new field table types that don't conflict
>> with the spec defined type codes.
>
>
>
> Agreed - we should agree QPID-wide ennhancements where we believe these are
> necessary, rather than having each client/broker add its own
> "enhancements". Obviously there has never been an intention to
> deliberately
> cause incompatibility with the spec (choosing conflicting field table
> types), however a wider review of such enhancements before they are made
> would hopefully reveal such bugs before they are implemented.
>
>
> Also, where we do consciously choose to go off spec it might not be a
>> bad idea to have some sort of negotiation at connection initiation so
>> that we can distinguish between plain vanilla clients and clients that
>> understand our extensions.
>
>
>
> My view is that hopefully the broker should do anything that will prevent
> clients talking to each other at the same "level" of the protocol. That is
> that two QPID clients should be able to communicate using our enhanced
> spec,
> but that the broker would equally well cope with two clients talking
> vanilla
> AMQP. The agreement is really between the two clients as to what protocol
> they speak which needs to be made at system deployment time rather than
> runtime I think.
This depends on the area of the enhancement/incompatibility. What you're
saying is mostly the case for message/header encoding issues. For those
features it's primarily the two clients that need to understand each
other and the broker can pretty much stay out of the way as long as it
can understand enough of the message to route it correctly.
For other kinds of spec changes it may be reasonable to allow clients
with different capabilities to interoperate, e.g. in principle there is
no reason that a vanilla 0-8 client couldn't publish a message to a
consumer that supports filters.
> I'm not sure that protocol negotiation would necessarily help. For
> instance, in the case we are talking about (FieldTables). the publishing
> client would negotiate to use QPID "enhanced". The potential recipient of
> the message negotiates to use vanilla AMQP. What should the broker do?
> Not
> send the message to the recipient because of the protocol version
> differences? Attempt to re-encode the message according to the negotiated
> protocol?
I'd say just generate a friendly error message. If we don't at a minimum
have a way to detect this situation then clients are going to connect
and die with a very cryptic error message somewhere in the depths of the
deserialization code.
> Hopefully this is only a relatively short term problem while the spec is
> eveolving. Once the spec is stable I would hope that QPID would no longer
> have any "enhancements" to worry about.
I agree it's worse now, but I suspect that our development will continue
to lead the spec even past the 1.0 version, in which case we will need
some kind of negotiation because we can't have all our clients and
brokers advertising AMQP 1.0 during negotiation and then using project
specific extensions.
--Rafael
Re: AMQP 0-9 support
Posted by Robert Godfrey <ro...@gmail.com>.
>
>
> Currently we don't actually support file and stream, just basic, so we
> won't really be in a different position with respect to spec compliance,
> we're just converting our basic support to message support.
Which is fine, but if we are working off the public spec then Basic is still
current whereas Message is marked as Work In Progress. We have to be very
clear that we are moving to virtual non-compliance with the published spec.
We are doing this for good reasons (i.e. we are confident that the spec will
move into conformance with QPID), but we will likely cease to be compatible
with any non-QPID AMQP implementations.
Personally I don't have an issue with getting ahead of the spec, I think
> we just need to be more careful about how we do it so that a) we don't
> break interoperability between the different qpid implementations at the
> very least, and b) so that we don't needlessly break compatibility with
> the spec when it would be just as easy to extend the spec, e.g. by
> choosing type codes for the new field table types that don't conflict
> with the spec defined type codes.
Agreed - we should agree QPID-wide ennhancements where we believe these are
necessary, rather than having each client/broker add its own
"enhancements". Obviously there has never been an intention to deliberately
cause incompatibility with the spec (choosing conflicting field table
types), however a wider review of such enhancements before they are made
would hopefully reveal such bugs before they are implemented.
Also, where we do consciously choose to go off spec it might not be a
> bad idea to have some sort of negotiation at connection initiation so
> that we can distinguish between plain vanilla clients and clients that
> understand our extensions.
My view is that hopefully the broker should do anything that will prevent
clients talking to each other at the same "level" of the protocol. That is
that two QPID clients should be able to communicate using our enhanced spec,
but that the broker would equally well cope with two clients talking vanilla
AMQP. The agreement is really between the two clients as to what protocol
they speak which needs to be made at system deployment time rather than
runtime I think.
I'm not sure that protocol negotiation would necessarily help. For
instance, in the case we are talking about (FieldTables). the publishing
client would negotiate to use QPID "enhanced". The potential recipient of
the message negotiates to use vanilla AMQP. What should the broker do? Not
send the message to the recipient because of the protocol version
differences? Attempt to re-encode the message according to the negotiated
protocol?
Hopefully this is only a relatively short term problem while the spec is
eveolving. Once the spec is stable I would hope that QPID would no longer
have any "enhancements" to worry about.
- Rob
Re: AMQP 0-9 support
Posted by Martin Ritchie <ri...@apache.org>.
On 17/01/07, Rafael Schloming <ra...@redhat.com> wrote:
>
>
> Robert Godfrey wrote:
> > Are you saying we will not support those parts of 0-9 which are also in 0-8
> > (i.e. Basic, File and Stream)?
> >
> > As far as I understand it, those are still in the spec although marked as
> > likely to be replaced. If we are claiming spec compliance should we not
> > still support these classes for the moment? If spec compliance is not our
> > goal (i.e. we are really anticipating a later version of the spec where
> > these elements have been removed) we should be clear about that. On other
> > threads we have been quite reluctant to get "ahead of the spec".
>
> Currently we don't actually support file and stream, just basic, so we
> won't really be in a different position with respect to spec compliance,
> we're just converting our basic support to message support.
>
> Personally I don't have an issue with getting ahead of the spec, I think
> we just need to be more careful about how we do it so that a) we don't
> break interoperability between the different qpid implementations at the
> very least, and b) so that we don't needlessly break compatibility with
> the spec when it would be just as easy to extend the spec, e.g. by
> choosing type codes for the new field table types that don't conflict
> with the spec defined type codes.
The conflicting type codes was just a mistake on my part. I took the
proposal that Robert Greig had started and implemented it. Neglecting
to check for conflicting types. Which of course there were with the
'S' type. Getting in the habbit of running the Python tests will help
improve our interop.
> Also, where we do consciously choose to go off spec it might not be a
> bad idea to have some sort of negotiation at connection initiation so
> that we can distinguish between plain vanilla clients and clients that
> understand our extensions.
>
> --Rafael
>
--
Martin Ritchie
Re: AMQP 0-9 support
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Godfrey wrote:
> Are you saying we will not support those parts of 0-9 which are also in 0-8
> (i.e. Basic, File and Stream)?
>
> As far as I understand it, those are still in the spec although marked as
> likely to be replaced. If we are claiming spec compliance should we not
> still support these classes for the moment? If spec compliance is not our
> goal (i.e. we are really anticipating a later version of the spec where
> these elements have been removed) we should be clear about that. On other
> threads we have been quite reluctant to get "ahead of the spec".
Currently we don't actually support file and stream, just basic, so we
won't really be in a different position with respect to spec compliance,
we're just converting our basic support to message support.
Personally I don't have an issue with getting ahead of the spec, I think
we just need to be more careful about how we do it so that a) we don't
break interoperability between the different qpid implementations at the
very least, and b) so that we don't needlessly break compatibility with
the spec when it would be just as easy to extend the spec, e.g. by
choosing type codes for the new field table types that don't conflict
with the spec defined type codes.
Also, where we do consciously choose to go off spec it might not be a
bad idea to have some sort of negotiation at connection initiation so
that we can distinguish between plain vanilla clients and clients that
understand our extensions.
--Rafael
Re: AMQP 0-9 support
Posted by John O'Hara <jo...@gmail.com>.
>
> I also strongly believe that we should create a JIRA category for spec
> issues in qpid, so that we can keep track if issues that we need to work
> around so that they can all be brought back to the AMQP Working Group
> and then once resolved we can update qpid to match and the resolution
> and close the JIRA issue
>
> Carl.
>
+1
Re: AMQP 0-9 support
Posted by Carl Trieloff <cc...@redhat.com>.
I checked the minutes today, and yes this is correct.
Carl.
John O'Hara wrote:
> Martin's interpretation is correct, and the word "checkpoint" was even
> used in the discussion at the AMQP WG.
>
> There is no a guarantee of inclusion of the WIP in 0-10. The AMQP WG
> decision was rather of a vote of confidence in the direction taken.
> See the extract from the minutes below.
>
> Motion:
> -----------
> "The Working Group vote to approve the progression of the Transport
> SIG proposal. The current 0.8 transport is not deprecated.
> The Transport SIG work will be incorporated into the next draft
> specification as a "Work In Progress" feature set, in the expectation
> it will be further enhanced and proved in an implementation."
>
> Motion passed 4 votes majority of the voting members.
> Transport is accepted as "Work in Progress" for publication in 0-9.
> ----------
>
>
> There is a discussion of the process over on the AMQP-DEV list, so I
> won't go on too much. It is reasonable to assume that given proper
> management of the PMC and it's members concerns that the WIP can be in
> 0-10; but it is *not* a certainty.
>
> To behave as if it were would be to disrespect the process and the
> members of the AMQP community.
>
> Regards
> John
Re: AMQP 0-9 support
Posted by John O'Hara <jo...@gmail.com>.
Martin's interpretation is correct, and the word "checkpoint" was even
used in the discussion at the AMQP WG.
There is no a guarantee of inclusion of the WIP in 0-10. The AMQP WG
decision was rather of a vote of confidence in the direction taken.
See the extract from the minutes below.
Motion:
-----------
"The Working Group vote to approve the progression of the Transport
SIG proposal. The current 0.8 transport is not deprecated.
The Transport SIG work will be incorporated into the next draft
specification as a "Work In Progress" feature set, in the expectation
it will be further enhanced and proved in an implementation."
Motion passed 4 votes majority of the voting members.
Transport is accepted as "Work in Progress" for publication in 0-9.
----------
There is a discussion of the process over on the AMQP-DEV list, so I
won't go on too much. It is reasonable to assume that given proper
management of the PMC and it's members concerns that the WIP can be in
0-10; but it is *not* a certainty.
To behave as if it were would be to disrespect the process and the
members of the AMQP community.
Regards
John
Re: AMQP 0-9 support
Posted by Carl Trieloff <cc...@redhat.com>.
Martin Ritchie wrote:
> On 24/01/07, Carl Trieloff <cc...@redhat.com> wrote:
>> Steve Vinoski wrote:
>> >
>> > So again, development items that cause significant disruption and
>> > churn, such as the maven switchover, persistence work, and protocol
>> > changes like 0-9, belong on a branch until stable, at which point they
>> > should be merged.
>> >
>>
>> I think that we might be talking past each other --- the goal is to get
>> the branch clean before merging. Thus no curn on the trunk. Whether to
>> merge or not is another matter - as the work has been voted in - and the
>> changes that Cisco requested is basically just another field to WIP that
>> seems like forward progress to me. Also note that we have other changes
>> on the trunk that are not in the spec yet / or even proposed which I
>> believe some other parties are going to propose. So if we have work that
>> has not been voted on yet, we can surely have work that has been voted
>> on and is marked for final inclusion in 0-10.
>
> I thought the WIP had just be 'checkpointed' i.e. agreement in the
> direction that the WIP is going but that doesn't guarantee inclusion
> for 0-10.
The vote was inclusion in 0-10 pending successful implementation.
> It is true that there are non spec compliant changes on
> trunk to enable JMS over AMQP but these changes should only cause
> problems when trying to interact with a Qpid JMS client. If the Qpid
> Java implementation had a separation between AMQP and JMS then an AMQP
> compliant Qpid Java client should be possible. Whither it is useful to
> have is a different question. As I believe anyone using the Qpid Java
> client will want to use the JMS API. That said, the Qpid clients
> should all be able to interact and exactly how JMS and AMQP should
> interoperate still needs to be worked out by the AMQP people.
Correct - I expect it might be 0-11 before we see a final AMQP - JMS mapping
chapter/appendix. I would thus make sure that all the issue we have with
the mapping
are raised now so that they can be included in the that work,
>
>> I also strongly believe that we should create a JIRA category for spec
>> issues in qpid, so that we can keep track if issues that we need to work
>> around so that they can all be brought back to the AMQP Working Group
>> and then once resolved we can update qpid to match and the resolution
>> and close the JIRA issue
>>
>> Carl.
>>
>
>
Re: AMQP 0-9 support
Posted by Martin Ritchie <ri...@apache.org>.
On 24/01/07, Carl Trieloff <cc...@redhat.com> wrote:
> Steve Vinoski wrote:
> >
> > So again, development items that cause significant disruption and
> > churn, such as the maven switchover, persistence work, and protocol
> > changes like 0-9, belong on a branch until stable, at which point they
> > should be merged.
> >
>
> I think that we might be talking past each other --- the goal is to get
> the branch clean before merging. Thus no curn on the trunk. Whether to
> merge or not is another matter - as the work has been voted in - and the
> changes that Cisco requested is basically just another field to WIP that
> seems like forward progress to me. Also note that we have other changes
> on the trunk that are not in the spec yet / or even proposed which I
> believe some other parties are going to propose. So if we have work that
> has not been voted on yet, we can surely have work that has been voted
> on and is marked for final inclusion in 0-10.
I thought the WIP had just be 'checkpointed' i.e. agreement in the
direction that the WIP is going but that doesn't guarantee inclusion
for 0-10. It is true that there are non spec compliant changes on
trunk to enable JMS over AMQP but these changes should only cause
problems when trying to interact with a Qpid JMS client. If the Qpid
Java implementation had a separation between AMQP and JMS then an AMQP
compliant Qpid Java client should be possible. Whither it is useful to
have is a different question. As I believe anyone using the Qpid Java
client will want to use the JMS API. That said, the Qpid clients
should all be able to interact and exactly how JMS and AMQP should
interoperate still needs to be worked out by the AMQP people.
> I also strongly believe that we should create a JIRA category for spec
> issues in qpid, so that we can keep track if issues that we need to work
> around so that they can all be brought back to the AMQP Working Group
> and then once resolved we can update qpid to match and the resolution
> and close the JIRA issue
>
> Carl.
>
--
Martin Ritchie
Re: AMQP 0-9 support
Posted by Carl Trieloff <cc...@redhat.com>.
Steve Vinoski wrote:
>
> So again, development items that cause significant disruption and
> churn, such as the maven switchover, persistence work, and protocol
> changes like 0-9, belong on a branch until stable, at which point they
> should be merged.
>
I think that we might be talking past each other --- the goal is to get
the branch clean before merging. Thus no curn on the trunk. Whether to
merge or not is another matter - as the work has been voted in - and the
changes that Cisco requested is basically just another field to WIP that
seems like forward progress to me. Also note that we have other changes
on the trunk that are not in the spec yet / or even proposed which I
believe some other parties are going to propose. So if we have work that
has not been voted on yet, we can surely have work that has been voted
on and is marked for final inclusion in 0-10.
I also strongly believe that we should create a JIRA category for spec
issues in qpid, so that we can keep track if issues that we need to work
around so that they can all be brought back to the AMQP Working Group
and then once resolved we can update qpid to match and the resolution
and close the JIRA issue
Carl.
Re: AMQP 0-9 support
Posted by Steve Vinoski <vi...@iona.com>.
I've been off on another mission for awhile and so have been silent
on this issue thus far. However, I'd like to chime back in and say
that I disagree with Carl that "the trunk should represent our
forward development," if by that he means that the trunk should
contain experimental and unproven features and functionality. I
believe we already break the trunk too much as it is -- I've seen
several cases recently where the Java trunk didn't even compile,
which is never good. The plan suggested a few weeks ago to do 0-9
work on trunk, thereby breaking it for "a week" (which almost
certainly would have turned into 2 or more weeks) would have been a
huge mistake IMO. As I said before, large items of work that cause
major churn, like 0-9 and like persistence, belong on a branch.
The model we used for M1 worked reasonably well. The Java trunk was
active and yet rarely broken for M1, and once we got to the point
where we decided it was functionally complete, we created the M1
release branch and finished it. That branch also serves as a "fixes
branch" for the M1 release for the future, if needed. This same
approach worked well for all the JMS work that followed M1 -- we
didn't create a release branch, but again, the trunk was rarely if
ever broken, yet at the same time it gained significant JMS
functionality. Meanwhile, Robert Grieg was off also working on a
persistence branch. Imagine if he had insisted on dragging half-
working persistence code onto trunk instead -- it would have
adversely affected every single user of trunk, whether they were a
committer or not, and would have significantly jeopardized the JMS work.
So again, development items that cause significant disruption and
churn, such as the maven switchover, persistence work, and protocol
changes like 0-9, belong on a branch until stable, at which point
they should be merged.
More comments below.
On Jan 23, 2007, at 11:18 AM, John O'Hara wrote:
> That's fine in principle if the trunk will fully support 0-8
> transport and
> WIP transport; in compliance with agreed 0-9 spec.
>
> If the new code is 0-8 only, that's too big a risk to swallow without
> proving it all out on the branch first.
> If we want to make changes to the WIP transport, as may be
> suggested by the
> recent lobbying by Cisco and iMatix, then we shouldn't be
> committing that
> level of churn to the mainline.
+1
> We need to reach some agreement on this.
> Myself and Robert are worried that dropping the 0-8 transport from
> trunk at
> this point will cause lots of immediate issues which prevent
> development of
> other important functions like improved persistence and fixing
> errors in TX
> handling.
+1
--steve
> Can you suggest a way forward that mitigates my concerns here?
> John
>
> On 23/01/07, Carl Trieloff <cc...@redhat.com> wrote:
>>
>>
>> John,
>>
>> I would not really agree, the trunk should represent our forward
>> development. If we want to create
>> stable releases, these should be done with a branch. It might even be
>> worth releases the branch as a M2.
>>
>> I was able to meet with a few other long term apache members last
>> week
>> while in business and asked about
>> creating branches for use as stable versions when project members
>> needed
>> them and that did not align with the
>> release cycle if the main project. This is done on other projects and
>> from what I can tell is accepted practice.
>>
>> Regards
>> Carl.
>>
>> John O'Hara wrote:
>> > One other thing. We'll be sending real business over the 0-9
>> (non-WIP)
>> > protocol.
>> > We want to be very very sure that the WIP transport has been
>> thoroughly
>> > tested before running it for real.
>> >
>> > That burden of proof should fall on the branch, imho.
>> >
>> > John
>> >
>> > On 23/01/07, John O'Hara <jo...@gmail.com> wrote:
>> >>
>> >> To be 0-9 compliant, you have to support the 0-8 framing by
>> default.
>> >> We can't ship at all if we're not compliant..... eating own dog
>> food
>> and
>> >> all that!
>> >>
>> >> Clients have to connect as version 99-0 to get the WIP framing.
>> >> If that in itself does not resolve the connection issue, then an
>> >> errata to
>> >> enable that detection should be added to the spec.
>> >>
>> >> Cheers
>> >> John
>> >>
>> >> On 17/01/07, Kim van der Riet <ki...@redhat.com> wrote:
>> >> >
>> >> > On Wed, 2007-01-17 at 13:11 +0000, Robert Godfrey wrote:
>> >> > > Are you saying we will not support those parts of 0-9 which
>> are
>> also
>> >> > in 0-8
>> >> > > (i.e. Basic, File and Stream)?
>> >> > >
>> >> > > As far as I understand it, those are still in the spec
>> although
>> >> marked
>> >> > as
>> >> > > likely to be replaced. If we are claiming spec compliance
>> should
>> we
>> >> > not
>> >> > > still support these classes for the moment? If spec
>> compliance
>> >> is not
>> >> > our
>> >> > > goal (i.e. we are really anticipating a later version of
>> the spec
>> >> > where
>> >> > > these elements have been removed) we should be clear about
>> that. On
>> >> > other
>> >> > > threads we have been quite reluctant to get "ahead of the
>> spec".
>> >> > >
>> >> > > - Rob
>> >> >
>> >> > IIRC, there are some difficulties in supporting both at the same
>> >> time -
>> >> > issues that the protocol does not resolve. For example, framing:
>> >> When a
>> >> > ProtocolInitiation is received by the broker, how does it know
>> whether
>> >> > to use the new request/response framing or old MethodBody
>> frame to
>> >> send
>> >> > the Connection.Start method?
>> >> >
>> >> > However, your question on how we label an implementation that
>> supports
>> >> > only 0-9 WIP is valid. It cannot be strictly 0-9 compliant, so
>> perhaps
>> >> > we should call it 0-9-WIP compliant instead.
>> >> >
>> >> > Kim
>> >> >
>> >> >
>> >>
>> >
>>
>>
Re: AMQP 0-9 support
Posted by Rafael Schloming <ra...@redhat.com>.
John O'Hara wrote:
> That's fine in principle if the trunk will fully support 0-8 transport and
> WIP transport; in compliance with agreed 0-9 spec.
>
> If the new code is 0-8 only, that's too big a risk to swallow without
> proving it all out on the branch first.
> If we want to make changes to the WIP transport, as may be suggested by the
> recent lobbying by Cisco and iMatix, then we shouldn't be committing that
> level of churn to the mainline.
>
> We need to reach some agreement on this.
> Myself and Robert are worried that dropping the 0-8 transport from trunk at
> this point will cause lots of immediate issues which prevent development of
> other important functions like improved persistence and fixing errors in TX
> handling.
>
> Can you suggest a way forward that mitigates my concerns here?
> John
I should point out that from the point of view of code stability and
given the current implementation it's almost meaningless to support
basic and message at the same time since the Java client implementation
has to pick one or the other, and obviously on the 0-9 branch it uses
the message class, so while we could add broker support for basic, it
would essentially be dead code. In theory we could run old Java clients
against the broker to test it, but not even this would really work due
to field table incompatibilities.
It's important to understand that what we've done on the branch isn't
actually deleting basic per se, we've renamed the basic event handlers
to respond to message events. All the same code and functionality is
there, it simply uses different class/method ids on the wire, and while
we could copy the event handlers in order to keep basic functioning,
IMHO that would ultimately lead to more bugs since we'd have two copies
of the event handlers, one of which would be dead code.
We could have taken a fancier approach that let us switch between
message and basic on the fly, but this would have been a bigger more
disruptive change. Once the branch is landed if we decide we don't want
to release without support for basic we can restructure the event
handlers in this way, but as long as we're on the branch there is
significant reason to avoid making any more structural changes than
necessary in order to minimize the effort and impact of landing the branch.
Ultimately I think the only real measure we have for the stability of
the code base is the tests themselves. So given this, I'd like to
suggest that all tests passing is the appropriate criteria to use for
landing the branch. I think delaying beyond this point will be
significantly counterproductive since we won't really learn anything
about the stability of the branch, and the delta between the branch and
trunk will continue to grow making the eventual merge both more work and
more destabilizing.
--Rafael
Re: AMQP 0-9 support
Posted by John O'Hara <jo...@gmail.com>.
That's fine in principle if the trunk will fully support 0-8 transport and
WIP transport; in compliance with agreed 0-9 spec.
If the new code is 0-8 only, that's too big a risk to swallow without
proving it all out on the branch first.
If we want to make changes to the WIP transport, as may be suggested by the
recent lobbying by Cisco and iMatix, then we shouldn't be committing that
level of churn to the mainline.
We need to reach some agreement on this.
Myself and Robert are worried that dropping the 0-8 transport from trunk at
this point will cause lots of immediate issues which prevent development of
other important functions like improved persistence and fixing errors in TX
handling.
Can you suggest a way forward that mitigates my concerns here?
John
On 23/01/07, Carl Trieloff <cc...@redhat.com> wrote:
>
>
> John,
>
> I would not really agree, the trunk should represent our forward
> development. If we want to create
> stable releases, these should be done with a branch. It might even be
> worth releases the branch as a M2.
>
> I was able to meet with a few other long term apache members last week
> while in business and asked about
> creating branches for use as stable versions when project members needed
> them and that did not align with the
> release cycle if the main project. This is done on other projects and
> from what I can tell is accepted practice.
>
> Regards
> Carl.
>
> John O'Hara wrote:
> > One other thing. We'll be sending real business over the 0-9 (non-WIP)
> > protocol.
> > We want to be very very sure that the WIP transport has been thoroughly
> > tested before running it for real.
> >
> > That burden of proof should fall on the branch, imho.
> >
> > John
> >
> > On 23/01/07, John O'Hara <jo...@gmail.com> wrote:
> >>
> >> To be 0-9 compliant, you have to support the 0-8 framing by default.
> >> We can't ship at all if we're not compliant..... eating own dog food
> and
> >> all that!
> >>
> >> Clients have to connect as version 99-0 to get the WIP framing.
> >> If that in itself does not resolve the connection issue, then an
> >> errata to
> >> enable that detection should be added to the spec.
> >>
> >> Cheers
> >> John
> >>
> >> On 17/01/07, Kim van der Riet <ki...@redhat.com> wrote:
> >> >
> >> > On Wed, 2007-01-17 at 13:11 +0000, Robert Godfrey wrote:
> >> > > Are you saying we will not support those parts of 0-9 which are
> also
> >> > in 0-8
> >> > > (i.e. Basic, File and Stream)?
> >> > >
> >> > > As far as I understand it, those are still in the spec although
> >> marked
> >> > as
> >> > > likely to be replaced. If we are claiming spec compliance should
> we
> >> > not
> >> > > still support these classes for the moment? If spec compliance
> >> is not
> >> > our
> >> > > goal (i.e. we are really anticipating a later version of the spec
> >> > where
> >> > > these elements have been removed) we should be clear about
> that. On
> >> > other
> >> > > threads we have been quite reluctant to get "ahead of the spec".
> >> > >
> >> > > - Rob
> >> >
> >> > IIRC, there are some difficulties in supporting both at the same
> >> time -
> >> > issues that the protocol does not resolve. For example, framing:
> >> When a
> >> > ProtocolInitiation is received by the broker, how does it know
> whether
> >> > to use the new request/response framing or old MethodBody frame to
> >> send
> >> > the Connection.Start method?
> >> >
> >> > However, your question on how we label an implementation that
> supports
> >> > only 0-9 WIP is valid. It cannot be strictly 0-9 compliant, so
> perhaps
> >> > we should call it 0-9-WIP compliant instead.
> >> >
> >> > Kim
> >> >
> >> >
> >>
> >
>
>
Re: AMQP 0-9 support
Posted by Carl Trieloff <cc...@redhat.com>.
John,
I would not really agree, the trunk should represent our forward
development. If we want to create
stable releases, these should be done with a branch. It might even be
worth releases the branch as a M2.
I was able to meet with a few other long term apache members last week
while in business and asked about
creating branches for use as stable versions when project members needed
them and that did not align with the
release cycle if the main project. This is done on other projects and
from what I can tell is accepted practice.
Regards
Carl.
John O'Hara wrote:
> One other thing. We'll be sending real business over the 0-9 (non-WIP)
> protocol.
> We want to be very very sure that the WIP transport has been thoroughly
> tested before running it for real.
>
> That burden of proof should fall on the branch, imho.
>
> John
>
> On 23/01/07, John O'Hara <jo...@gmail.com> wrote:
>>
>> To be 0-9 compliant, you have to support the 0-8 framing by default.
>> We can't ship at all if we're not compliant..... eating own dog food and
>> all that!
>>
>> Clients have to connect as version 99-0 to get the WIP framing.
>> If that in itself does not resolve the connection issue, then an
>> errata to
>> enable that detection should be added to the spec.
>>
>> Cheers
>> John
>>
>> On 17/01/07, Kim van der Riet <ki...@redhat.com> wrote:
>> >
>> > On Wed, 2007-01-17 at 13:11 +0000, Robert Godfrey wrote:
>> > > Are you saying we will not support those parts of 0-9 which are also
>> > in 0-8
>> > > (i.e. Basic, File and Stream)?
>> > >
>> > > As far as I understand it, those are still in the spec although
>> marked
>> > as
>> > > likely to be replaced. If we are claiming spec compliance should we
>> > not
>> > > still support these classes for the moment? If spec compliance
>> is not
>> > our
>> > > goal (i.e. we are really anticipating a later version of the spec
>> > where
>> > > these elements have been removed) we should be clear about that. On
>> > other
>> > > threads we have been quite reluctant to get "ahead of the spec".
>> > >
>> > > - Rob
>> >
>> > IIRC, there are some difficulties in supporting both at the same
>> time -
>> > issues that the protocol does not resolve. For example, framing:
>> When a
>> > ProtocolInitiation is received by the broker, how does it know whether
>> > to use the new request/response framing or old MethodBody frame to
>> send
>> > the Connection.Start method?
>> >
>> > However, your question on how we label an implementation that supports
>> > only 0-9 WIP is valid. It cannot be strictly 0-9 compliant, so perhaps
>> > we should call it 0-9-WIP compliant instead.
>> >
>> > Kim
>> >
>> >
>>
>
Re: AMQP 0-9 support
Posted by John O'Hara <jo...@gmail.com>.
One other thing. We'll be sending real business over the 0-9 (non-WIP)
protocol.
We want to be very very sure that the WIP transport has been thoroughly
tested before running it for real.
That burden of proof should fall on the branch, imho.
John
On 23/01/07, John O'Hara <jo...@gmail.com> wrote:
>
> To be 0-9 compliant, you have to support the 0-8 framing by default.
> We can't ship at all if we're not compliant..... eating own dog food and
> all that!
>
> Clients have to connect as version 99-0 to get the WIP framing.
> If that in itself does not resolve the connection issue, then an errata to
> enable that detection should be added to the spec.
>
> Cheers
> John
>
> On 17/01/07, Kim van der Riet <ki...@redhat.com> wrote:
> >
> > On Wed, 2007-01-17 at 13:11 +0000, Robert Godfrey wrote:
> > > Are you saying we will not support those parts of 0-9 which are also
> > in 0-8
> > > (i.e. Basic, File and Stream)?
> > >
> > > As far as I understand it, those are still in the spec although marked
> > as
> > > likely to be replaced. If we are claiming spec compliance should we
> > not
> > > still support these classes for the moment? If spec compliance is not
> > our
> > > goal (i.e. we are really anticipating a later version of the spec
> > where
> > > these elements have been removed) we should be clear about that. On
> > other
> > > threads we have been quite reluctant to get "ahead of the spec".
> > >
> > > - Rob
> >
> > IIRC, there are some difficulties in supporting both at the same time -
> > issues that the protocol does not resolve. For example, framing: When a
> > ProtocolInitiation is received by the broker, how does it know whether
> > to use the new request/response framing or old MethodBody frame to send
> > the Connection.Start method?
> >
> > However, your question on how we label an implementation that supports
> > only 0-9 WIP is valid. It cannot be strictly 0-9 compliant, so perhaps
> > we should call it 0-9-WIP compliant instead.
> >
> > Kim
> >
> >
>
Re: AMQP 0-9 support
Posted by John O'Hara <jo...@gmail.com>.
To be 0-9 compliant, you have to support the 0-8 framing by default.
We can't ship at all if we're not compliant..... eating own dog food and all
that!
Clients have to connect as version 99-0 to get the WIP framing.
If that in itself does not resolve the connection issue, then an errata to
enable that detection should be added to the spec.
Cheers
John
On 17/01/07, Kim van der Riet <ki...@redhat.com> wrote:
>
> On Wed, 2007-01-17 at 13:11 +0000, Robert Godfrey wrote:
> > Are you saying we will not support those parts of 0-9 which are also in
> 0-8
> > (i.e. Basic, File and Stream)?
> >
> > As far as I understand it, those are still in the spec although marked
> as
> > likely to be replaced. If we are claiming spec compliance should we not
> > still support these classes for the moment? If spec compliance is not
> our
> > goal (i.e. we are really anticipating a later version of the spec where
> > these elements have been removed) we should be clear about that. On
> other
> > threads we have been quite reluctant to get "ahead of the spec".
> >
> > - Rob
>
> IIRC, there are some difficulties in supporting both at the same time -
> issues that the protocol does not resolve. For example, framing: When a
> ProtocolInitiation is received by the broker, how does it know whether
> to use the new request/response framing or old MethodBody frame to send
> the Connection.Start method?
>
> However, your question on how we label an implementation that supports
> only 0-9 WIP is valid. It cannot be strictly 0-9 compliant, so perhaps
> we should call it 0-9-WIP compliant instead.
>
> Kim
>
>
Re: AMQP 0-9 support
Posted by Kim van der Riet <ki...@redhat.com>.
On Wed, 2007-01-17 at 15:18 +0000, Gordon Sim wrote:
> Kim van der Riet wrote:
> > On Wed, 2007-01-17 at 14:43 +0000, Martin Ritchie wrote:
> >> On 17/01/07, Kim van der Riet <ki...@redhat.com> wrote:
> >>> IIRC, there are some difficulties in supporting both at the same time -
> >>> issues that the protocol does not resolve. For example, framing: When a
> >>> ProtocolInitiation is received by the broker, how does it know whether
> >>> to use the new request/response framing or old MethodBody frame to send
> >>> the Connection.Start method?
> >> I thought the ProtocolInitialisation was used to negotiate the version
> >> for the connection so it would know what versions it supported. If it
> >> supported both it would return the correct frame MethodBody or
> >> Connection.Start if it didn't support the version presented it would
> >> just close the Connection.
> >
> > But if we successfully negotiate a 0-9 connection on a broker which
> > supports both the new (Request/Response) AND the old (MethodBody)
> > framing - so as to be 0-9 and 0-9-WIP compliant, which would be used to
> > start the connection? It seems to me that there is no way for the client
> > to inform the broker up front.
>
> Wasn't the 99 major number reserved for WIP type work? Can we claim the
> 99-1 id for the WIP sections of 0-9?
Good suggestion.
Kim
Re: AMQP 0-9 support
Posted by Gordon Sim <gs...@redhat.com>.
Rafael Schloming wrote:
> so the only
> reason I can see for us to keep basic is if we want to choose right now
> to start being pedantic about spec compliance.
[...]
> It would certainly be possible to support both versions, however in my
> view this would be a waste of time. The only circumstance under which
> this would help us is in the *extremely* unlikely event that the working
> group decides to entirely remove the WIP portions for 0-10 and regress
> the protocol to 0-8, and even then we might as well wait until that
> point to do the work since it wouldn't be significantly more difficult
> then than it would be right now.
[...]
> I think the trunk should reflect the direction the spec is moving, which
> is in this case towards the 0-9 WIP, as well as towards JMS
> interoperability. It would certainly be possible to support full 0-9 on
> the trunk, but as I said above there is really no tangible benefit other
> than we could say we're being sorta but not really pedantic about trunk
> compliance.
[...]
The point of compliance is that it allows users to use implementations
of the same spec version from different sources in the same system. I'm
not advocating that we adopt a pedantic, legalistic view of compliance
that impedes development while the spec as well as the implementation is
in flux. However I do think it is important to be clear about what users
can expect if they do decide to try to mix different implementations.
One obvious benefit of an implementation of the 0-9 'core' spec would be
that a user could deploy it in a system in which there were other
implementations of that protocol[1]. I can't say whether this benefit
would be realised by anyone or whether it would be worth the effort or
not. So to me the issue is less about being pedantic about policy and
more about trying to anticipate what users might want (never easy!).
[1] Another benefit might be that other implementations can use some of
our code to validate or bootstrap their own implementations of the 0-9 core.
Re: AMQP 0-9 support
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Godfrey wrote:
>> Why not? The WIP portion of the spec is essentially a refactoring of
>> basic, stream, and file + additional framing level changes to support
>> HA. The broker should be able to be fully as functional as it is now
>> (more functional hopefully) without using basic.
>
>
>
> I wholeheartedly agree that we expect the functionality to be better once
> the spec is complete and implemented. I guess my issue is that
> currently we
> (as in where I work) are aiming to deploy builds based on stable cuts of
> the
> trunk code. I may be being overly nervous here, but we seem to be
> moving to
> a place where trunk does not comply to any version of the spec only to
> pieces of the 0-9 spec that are explictly marked Work In Progress. Further
> if we remove the 0-8 like parts we do not have anything to fall back on if
> we find conceptual bugs in the 0-9 WIP (not saying it's going to happen,
> but
> as you say it is a proof of concept at the moment).
I didn't say 0-9 WIP was a proof of concept. I said the Qpid
implementation of it is supposed to be a proof of concept. I fully
expect we will find gaps in the 0-9 portion of the spec, the same way
we've found gaps when trying to implement JMS over 0-8. That is
precisely the reason it is labeled WIP, because it has no implementation
yet. I believe we are fully expected to implement any extensions
necessary to support the required functionality, and those extensions
will be incorporated into 0-10.
> I think our concerns may differ because of the different positions we are
> in, and I hope I do not mis-represent your position here... I am looking to
> support applications already in (or about to go in to) production with
> QPID. You are looking to the future and the functionality we need to have
> to support a wider range of use cases. I don't want to lose the current
> 0-8
> like functionality until it can be proven to be superceded by the 0-9 WIP
> stuff. You want to prove that the 0-9 WIP work supercedes the 0-8 style.
> My take was the reason that the 0-9 protocol included both the 0-8 and the
> WIP styles was to allow a period of transition and to allow us to shake out
> any problems with the 0-9 WIP protocol.
Just to be clear there will be no feature regressions required to
support 0-9 WIP, it will in fact be quite the opposite, since the 0-9
WIP protocol will enable us to support features we don't currently have,
and as I mentioned above we are expected to extend the protocol where
necessary in order to avoid regressions, so all in all there will be a
more limited set of features available to 0-8 clients, so the only
reason I can see for us to keep basic is if we want to choose right now
to start being pedantic about spec compliance.
>> We could do that, but that would be more work with no benefit other than
>> to be able to say we officially conform to the spec, which I don't think
>> we can say in any meaningful way at this point anyways.
>>
>> Also, Qpid is supposed to be the proof of concept implementation that
>> allows the 0-9 WIP stuff to become the 0-10 version of the spec, and so
>> one of the things we need to demonstrate is that we won't actually be
>> losing functionality by removing basic, stream, and file, and the
>> easiest way to do that is to actually remove them.
>
>
> I've absolutely no objection to a branch build with the 0-8 stuff turned
> off... I would just prefer to see a spec compliant build on trunk.
> Although
> the possibility may be remote, I do not think that we should remove the 0-8
> style on trunk until that becomes official AMQ spec, otherwise we will
> be in
> a difficult position if the AMQ committee does not agree on moving forward
> with the WIP protocol, or if there are major revisions to it (again - I
> think that is unlikely, but we should not take anything for granted).
It would certainly be possible to support both versions, however in my
view this would be a waste of time. The only circumstance under which
this would help us is in the *extremely* unlikely event that the working
group decides to entirely remove the WIP portions for 0-10 and regress
the protocol to 0-8, and even then we might as well wait until that
point to do the work since it wouldn't be significantly more difficult
then than it would be right now.
> I'd really like to get some other people's input here, but my desire would
> be that we attempt to keep trunk as compliant as possible with at most us
> having enhancements *over* the spec, not choosing to not implement large
> parts of it. If we wish to simultaneously use a branch to demonstrate a
> proof of concept that the protocol without Basic etc is sufficient, I think
> that is great. Therefore if it isn't easy to properly implement 0-9 as
> written, then perhaps we should skip 0-9 compliance. On the branch we can
> do a proof of concept for 0-10, and on trunk we can keep on 0-8. If we can
> properly conform to 0-9 then that should be on trunk, with proof of concept
> for 0-10 simply being to turn off Basic etc...
I think the trunk should reflect the direction the spec is moving, which
is in this case towards the 0-9 WIP, as well as towards JMS
interoperability. It would certainly be possible to support full 0-9 on
the trunk, but as I said above there is really no tangible benefit other
than we could say we're being sorta but not really pedantic about trunk
compliance.
As for the difference between enhancements *over* the spec and "choosing
not to implement large parts of it." I believe it is well understood
that the 0-9 WIP is intended to supersede basic in 0-10, so I don't
believe it's as bad as arbitrarily choosing not to implement large parts
of the spec.
--Rafael
Re: AMQP 0-9 support
Posted by Carl Trieloff <cc...@redhat.com>.
Robert Godfrey wrote:
>>
>>
>>
>> Why not? The WIP portion of the spec is essentially a refactoring of
>> basic, stream, and file + additional framing level changes to support
>> HA. The broker should be able to be fully as functional as it is now
>> (more functional hopefully) without using basic.
>
>
>
> I wholeheartedly agree that we expect the functionality to be better once
> the spec is complete and implemented. I guess my issue is that
> currently we
> (as in where I work) are aiming to deploy builds based on stable cuts
> of the
> trunk code. I may be being overly nervous here, but we seem to be
> moving to
> a place where trunk does not comply to any version of the spec only to
> pieces of the 0-9 spec that are explictly marked Work In Progress.
> Further
> if we remove the 0-8 like parts we do not have anything to fall back
> on if
> we find conceptual bugs in the 0-9 WIP (not saying it's going to
> happen, but
> as you say it is a proof of concept at the moment).
>
> I think our concerns may differ because of the different positions we are
> in, and I hope I do not mis-represent your position here... I am
> looking to
> support applications already in (or about to go in to) production with
> QPID. You are looking to the future and the functionality we need to
> have
> to support a wider range of use cases. I don't want to lose the
> current 0-8
> like functionality until it can be proven to be superceded by the 0-9 WIP
> stuff. You want to prove that the 0-9 WIP work supercedes the 0-8 style.
> My take was the reason that the 0-9 protocol included both the 0-8 and
> the
> WIP styles was to allow a period of transition and to allow us to
> shake out
> any problems with the 0-9 WIP protocol.
>
>
>>
>> We could do that, but that would be more work with no benefit other than
>> to be able to say we officially conform to the spec, which I don't think
>> we can say in any meaningful way at this point anyways.
>>
>> Also, Qpid is supposed to be the proof of concept implementation that
>> allows the 0-9 WIP stuff to become the 0-10 version of the spec, and so
>> one of the things we need to demonstrate is that we won't actually be
>> losing functionality by removing basic, stream, and file, and the
>> easiest way to do that is to actually remove them.
>
>
> I've absolutely no objection to a branch build with the 0-8 stuff turned
> off... I would just prefer to see a spec compliant build on trunk.
> Although
> the possibility may be remote, I do not think that we should remove
> the 0-8
> style on trunk until that becomes official AMQ spec, otherwise we will
> be in
> a difficult position if the AMQ committee does not agree on moving
> forward
> with the WIP protocol, or if there are major revisions to it (again - I
> think that is unlikely, but we should not take anything for granted).
>
> I'd really like to get some other people's input here, but my desire
> would
> be that we attempt to keep trunk as compliant as possible with at most us
> having enhancements *over* the spec, not choosing to not implement large
> parts of it. If we wish to simultaneously use a branch to demonstrate a
> proof of concept that the protocol without Basic etc is sufficient, I
> think
> that is great. Therefore if it isn't easy to properly implement 0-9 as
> written, then perhaps we should skip 0-9 compliance. On the branch we
> can
> do a proof of concept for 0-10, and on trunk we can keep on 0-8. If
> we can
> properly conform to 0-9 then that should be on trunk, with proof of
> concept
> for 0-10 simply being to turn off Basic etc...
>
> - Rob
>
If it is inevitable that we will move to 0-9/ 0-10 etc and the way the
spec is going why should it not be truck. We would want the trunk to
track where the spec is going and then we create a branch to support 0-8
which is just one frozen version in time. Given that there are other
merges on trunk for JMS for example that are not compliant and being
worked by the spec group why should they not all be truck?
The requirement for stable sets of functionality for production should
not be met by the trunk as that will highly hamstring the forward
progress of the project. Under that reasoning cluster or persistence or
any other work should also not be merged to trunk. Thus, I have no
issues creating a snapshot, and even helping maintain it or branch until
we get to the next deployable point on the trunk. I think we need to
make sure that we can progress the project and make sure that our users
and those wanting to deploy can get stable versions. I think that we
might want to create a branch snapshot for deployments now, and then
plan a stable release of the project towards the end of the quarter
which can co-inside with 0-10 spec release and be as close to compliant
with that as possible
Thoughts...
Carl.
Re: AMQP 0-9 support
Posted by Robert Godfrey <ro...@gmail.com>.
>
>
>
> Why not? The WIP portion of the spec is essentially a refactoring of
> basic, stream, and file + additional framing level changes to support
> HA. The broker should be able to be fully as functional as it is now
> (more functional hopefully) without using basic.
I wholeheartedly agree that we expect the functionality to be better once
the spec is complete and implemented. I guess my issue is that currently we
(as in where I work) are aiming to deploy builds based on stable cuts of the
trunk code. I may be being overly nervous here, but we seem to be moving to
a place where trunk does not comply to any version of the spec only to
pieces of the 0-9 spec that are explictly marked Work In Progress. Further
if we remove the 0-8 like parts we do not have anything to fall back on if
we find conceptual bugs in the 0-9 WIP (not saying it's going to happen, but
as you say it is a proof of concept at the moment).
I think our concerns may differ because of the different positions we are
in, and I hope I do not mis-represent your position here... I am looking to
support applications already in (or about to go in to) production with
QPID. You are looking to the future and the functionality we need to have
to support a wider range of use cases. I don't want to lose the current 0-8
like functionality until it can be proven to be superceded by the 0-9 WIP
stuff. You want to prove that the 0-9 WIP work supercedes the 0-8 style.
My take was the reason that the 0-9 protocol included both the 0-8 and the
WIP styles was to allow a period of transition and to allow us to shake out
any problems with the 0-9 WIP protocol.
>
> We could do that, but that would be more work with no benefit other than
> to be able to say we officially conform to the spec, which I don't think
> we can say in any meaningful way at this point anyways.
>
> Also, Qpid is supposed to be the proof of concept implementation that
> allows the 0-9 WIP stuff to become the 0-10 version of the spec, and so
> one of the things we need to demonstrate is that we won't actually be
> losing functionality by removing basic, stream, and file, and the
> easiest way to do that is to actually remove them.
I've absolutely no objection to a branch build with the 0-8 stuff turned
off... I would just prefer to see a spec compliant build on trunk. Although
the possibility may be remote, I do not think that we should remove the 0-8
style on trunk until that becomes official AMQ spec, otherwise we will be in
a difficult position if the AMQ committee does not agree on moving forward
with the WIP protocol, or if there are major revisions to it (again - I
think that is unlikely, but we should not take anything for granted).
I'd really like to get some other people's input here, but my desire would
be that we attempt to keep trunk as compliant as possible with at most us
having enhancements *over* the spec, not choosing to not implement large
parts of it. If we wish to simultaneously use a branch to demonstrate a
proof of concept that the protocol without Basic etc is sufficient, I think
that is great. Therefore if it isn't easy to properly implement 0-9 as
written, then perhaps we should skip 0-9 compliance. On the branch we can
do a proof of concept for 0-10, and on trunk we can keep on 0-8. If we can
properly conform to 0-9 then that should be on trunk, with proof of concept
for 0-10 simply being to turn off Basic etc...
- Rob
Re: AMQP 0-9 support
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Godfrey wrote:
> I think we would be quite nervous about removing all support for the old
> classes. I guess I was misunderstanding exactly what was being
> attempted in
> the 0-9 support branch. I thought we would be aiming for supporting the
> 0-9
> spec as publicly released, not just the WIP parts. Certainly we could not
> deploy anything in this state.
Why not? The WIP portion of the spec is essentially a refactoring of
basic, stream, and file + additional framing level changes to support
HA. The broker should be able to be fully as functional as it is now
(more functional hopefully) without using basic.
> For those of us supporting QPID implementations in production, I think we
> should aim to support the published version of the specification.
> Otherwise
> we should wait until the specification deprecates the old framing and
> Request/Response ceases to be WIP (0-10?).
We could do that, but that would be more work with no benefit other than
to be able to say we officially conform to the spec, which I don't think
we can say in any meaningful way at this point anyways.
Also, Qpid is supposed to be the proof of concept implementation that
allows the 0-9 WIP stuff to become the 0-10 version of the spec, and so
one of the things we need to demonstrate is that we won't actually be
losing functionality by removing basic, stream, and file, and the
easiest way to do that is to actually remove them.
--Rafael
Re: AMQP 0-9 support
Posted by Robert Godfrey <ro...@gmail.com>.
I think we would be quite nervous about removing all support for the old
classes. I guess I was misunderstanding exactly what was being attempted in
the 0-9 support branch. I thought we would be aiming for supporting the 0-9
spec as publicly released, not just the WIP parts. Certainly we could not
deploy anything in this state.
For those of us supporting QPID implementations in production, I think we
should aim to support the published version of the specification. Otherwise
we should wait until the specification deprecates the old framing and
Request/Response ceases to be WIP (0-10?).
- Rob
Re: AMQP 0-9 support
Posted by Alan Conway <ac...@redhat.com>.
On Wed, 2007-01-17 at 15:36 +0000, Gordon Sim wrote:
> Alan Conway wrote:
> I don't see a need to provide interop between 0.8 and 0-9.
Me neither.
> My question
> was whether we aim to be 0-9 'compliant' and whether that would be
> possible if we only implemented the WIP parts. When you say 'we are
> first aiming to get 0-9 working' do you mean the WIP part only?
Yes. Right now the C++ branch doesn't comply with anything. I want to
get WIP framing & message class working first, then add back Basic (over
new framing) and finally protocol detection and old framing option
(allowing WIP or Basic over old or new framing.)
Cheers,
Alan.
Re: AMQP 0-9 support
Posted by Gordon Sim <gs...@redhat.com>.
Alan Conway wrote:
> On Wed, 2007-01-17 at 15:18 +0000, Gordon Sim wrote:
>>> But if we successfully negotiate a 0-9 connection on a broker which
>>> supports both the new (Request/Response) AND the old (MethodBody)
>>> framing - so as to be 0-9 and 0-9-WIP compliant, which would be used to
>>> start the connection? It seems to me that there is no way for the client
>>> to inform the broker up front.
>> Wasn't the 99 major number reserved for WIP type work? Can we claim the
>> 99-1 id for the WIP sections of 0-9?
>
> The situation with C++ is not too bad. We won't support 0-8 in the first
> cut but we haven't ditched any of the basic stuff or the old framing,
> it's just disconnected. I think it might be fairly straightforward to
> reconnect it conditionally.
>
> So I'd say the C++ position is: we are first aiming to get 0-9 working
> without 0-8. We wont slow ourselves down worrying about 0-8 but we wont
> needlessly throw 0-8 stuff away either.Once 0-9 works we can look at
> re-enabling 0-8 conditionally, and it might not be as hard as I
> originally thought.
>
> We might get a multi-version broker out of this yet- but it's not top
> priority.
I don't see a need to provide interop between 0.8 and 0-9. My question
was whether we aim to be 0-9 'compliant' and whether that would be
possible if we only implemented the WIP parts. When you say 'we are
first aiming to get 0-9 working' do you mean the WIP part only?
Re: AMQP 0-9 support
Posted by Alan Conway <ac...@redhat.com>.
On Wed, 2007-01-17 at 15:18 +0000, Gordon Sim wrote:
> > But if we successfully negotiate a 0-9 connection on a broker which
> > supports both the new (Request/Response) AND the old (MethodBody)
> > framing - so as to be 0-9 and 0-9-WIP compliant, which would be used to
> > start the connection? It seems to me that there is no way for the client
> > to inform the broker up front.
>
> Wasn't the 99 major number reserved for WIP type work? Can we claim the
> 99-1 id for the WIP sections of 0-9?
The situation with C++ is not too bad. We won't support 0-8 in the first
cut but we haven't ditched any of the basic stuff or the old framing,
it's just disconnected. I think it might be fairly straightforward to
reconnect it conditionally.
So I'd say the C++ position is: we are first aiming to get 0-9 working
without 0-8. We wont slow ourselves down worrying about 0-8 but we wont
needlessly throw 0-8 stuff away either.Once 0-9 works we can look at
re-enabling 0-8 conditionally, and it might not be as hard as I
originally thought.
We might get a multi-version broker out of this yet- but it's not top
priority.
Cheers,
Alan.
Re: AMQP 0-9 support
Posted by Gordon Sim <gs...@redhat.com>.
Kim van der Riet wrote:
> On Wed, 2007-01-17 at 14:43 +0000, Martin Ritchie wrote:
>> On 17/01/07, Kim van der Riet <ki...@redhat.com> wrote:
>>> IIRC, there are some difficulties in supporting both at the same time -
>>> issues that the protocol does not resolve. For example, framing: When a
>>> ProtocolInitiation is received by the broker, how does it know whether
>>> to use the new request/response framing or old MethodBody frame to send
>>> the Connection.Start method?
>> I thought the ProtocolInitialisation was used to negotiate the version
>> for the connection so it would know what versions it supported. If it
>> supported both it would return the correct frame MethodBody or
>> Connection.Start if it didn't support the version presented it would
>> just close the Connection.
>
> But if we successfully negotiate a 0-9 connection on a broker which
> supports both the new (Request/Response) AND the old (MethodBody)
> framing - so as to be 0-9 and 0-9-WIP compliant, which would be used to
> start the connection? It seems to me that there is no way for the client
> to inform the broker up front.
Wasn't the 99 major number reserved for WIP type work? Can we claim the
99-1 id for the WIP sections of 0-9?
Re: AMQP 0-9 support
Posted by Kim van der Riet <ki...@redhat.com>.
On Wed, 2007-01-17 at 14:43 +0000, Martin Ritchie wrote:
> On 17/01/07, Kim van der Riet <ki...@redhat.com> wrote:
> > IIRC, there are some difficulties in supporting both at the same time -
> > issues that the protocol does not resolve. For example, framing: When a
> > ProtocolInitiation is received by the broker, how does it know whether
> > to use the new request/response framing or old MethodBody frame to send
> > the Connection.Start method?
>
> I thought the ProtocolInitialisation was used to negotiate the version
> for the connection so it would know what versions it supported. If it
> supported both it would return the correct frame MethodBody or
> Connection.Start if it didn't support the version presented it would
> just close the Connection.
But if we successfully negotiate a 0-9 connection on a broker which
supports both the new (Request/Response) AND the old (MethodBody)
framing - so as to be 0-9 and 0-9-WIP compliant, which would be used to
start the connection? It seems to me that there is no way for the client
to inform the broker up front.
Kim
Re: AMQP 0-9 support
Posted by Martin Ritchie <ri...@apache.org>.
On 17/01/07, Kim van der Riet <ki...@redhat.com> wrote:
> On Wed, 2007-01-17 at 13:11 +0000, Robert Godfrey wrote:
> > Are you saying we will not support those parts of 0-9 which are also in 0-8
> > (i.e. Basic, File and Stream)?
> >
> > As far as I understand it, those are still in the spec although marked as
> > likely to be replaced. If we are claiming spec compliance should we not
> > still support these classes for the moment? If spec compliance is not our
> > goal (i.e. we are really anticipating a later version of the spec where
> > these elements have been removed) we should be clear about that. On other
> > threads we have been quite reluctant to get "ahead of the spec".
> >
> > - Rob
>
> IIRC, there are some difficulties in supporting both at the same time -
> issues that the protocol does not resolve. For example, framing: When a
> ProtocolInitiation is received by the broker, how does it know whether
> to use the new request/response framing or old MethodBody frame to send
> the Connection.Start method?
I thought the ProtocolInitialisation was used to negotiate the version
for the connection so it would know what versions it supported. If it
supported both it would return the correct frame MethodBody or
Connection.Start if it didn't support the version presented it would
just close the Connection.
> However, your question on how we label an implementation that supports
> only 0-9 WIP is valid. It cannot be strictly 0-9 compliant, so perhaps
> we should call it 0-9-WIP compliant instead.
>
> Kim
>
>
--
Martin Ritchie
Re: AMQP 0-9 support
Posted by Kim van der Riet <ki...@redhat.com>.
On Wed, 2007-01-17 at 13:11 +0000, Robert Godfrey wrote:
> Are you saying we will not support those parts of 0-9 which are also in 0-8
> (i.e. Basic, File and Stream)?
>
> As far as I understand it, those are still in the spec although marked as
> likely to be replaced. If we are claiming spec compliance should we not
> still support these classes for the moment? If spec compliance is not our
> goal (i.e. we are really anticipating a later version of the spec where
> these elements have been removed) we should be clear about that. On other
> threads we have been quite reluctant to get "ahead of the spec".
>
> - Rob
IIRC, there are some difficulties in supporting both at the same time -
issues that the protocol does not resolve. For example, framing: When a
ProtocolInitiation is received by the broker, how does it know whether
to use the new request/response framing or old MethodBody frame to send
the Connection.Start method?
However, your question on how we label an implementation that supports
only 0-9 WIP is valid. It cannot be strictly 0-9 compliant, so perhaps
we should call it 0-9-WIP compliant instead.
Kim
Re: AMQP 0-9 support
Posted by Robert Godfrey <ro...@gmail.com>.
Are you saying we will not support those parts of 0-9 which are also in 0-8
(i.e. Basic, File and Stream)?
As far as I understand it, those are still in the spec although marked as
likely to be replaced. If we are claiming spec compliance should we not
still support these classes for the moment? If spec compliance is not our
goal (i.e. we are really anticipating a later version of the spec where
these elements have been removed) we should be clear about that. On other
threads we have been quite reluctant to get "ahead of the spec".
- Rob
Re: AMQP 0-9 support
Posted by Kim van der Riet <ki...@redhat.com>.
On Wed, 2007-01-17 at 12:25 +0000, Gordon Sim wrote:
> Are we planning that our 0-9 branches will support both the core
> protocol and the WIP additions? If so would we do that simultaneously
> (i.e. a single broker could do both)?
My understanding is that we are replacing older 0-8 Basic, File and
Stream classes and the Message/ContentHeader/Content framing with the
0-9 WIP sections (i.e. new request/response framing and the Message
class). When this is complete, we will have a working implementation
that supports only the new 0-9 WIP spec.
Kim
Re: AMQP 0-9 support
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2007-01-17 at 12:25 +0000, Gordon Sim wrote:
> Are we planning that our 0-9 branches will support both the core
> protocol and the WIP additions? If so would we do that simultaneously
> (i.e. a single broker could do both)?
AFAIK The plan is that the 0-9 branch won't support the 0.8 protocol at
the same time - the current state of the c++ code is just so that the
tests keep on passing and the code keeps compiling, we plan to remove
Basic etc.
Andrew