Re: AMQP 0-9 support
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
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
Martin Ritchie wrote: On 24/01/07, Carl Trieloff <[EMAIL PROTECTED]> 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
On 24/01/07, Carl Trieloff <[EMAIL PROTECTED]> 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
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
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
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
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: >> > >> > On Wed, 2007-01-17 at 13:11 +, 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 diffic
Re: AMQP 0-9 support
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: >> > >> > On Wed, 2007-01-17 at 13:11 +, 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
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-01-17 at 13:11 +, 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
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-01-17 at 13:11 +, 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
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 <[EMAIL PROTECTED]> wrote: On Wed, 2007-01-17 at 13:11 +, 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
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
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 refle
Re: AMQP 0-9 support
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
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
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
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
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
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
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
On Wed, 2007-01-17 at 15:36 +, 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
Alan Conway wrote: On Wed, 2007-01-17 at 15:18 +, 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
On Wed, 2007-01-17 at 15:18 +, 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
On Wed, 2007-01-17 at 15:18 +, Gordon Sim wrote: > Kim van der Riet wrote: > > On Wed, 2007-01-17 at 14:43 +, Martin Ritchie wrote: > >> On 17/01/07, Kim van der Riet <[EMAIL PROTECTED]> 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
Kim van der Riet wrote: On Wed, 2007-01-17 at 14:43 +, Martin Ritchie wrote: On 17/01/07, Kim van der Riet <[EMAIL PROTECTED]> 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
On Wed, 2007-01-17 at 14:43 +, Martin Ritchie wrote: > On 17/01/07, Kim van der Riet <[EMAIL PROTECTED]> 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
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
On 17/01/07, Kim van der Riet <[EMAIL PROTECTED]> wrote: On Wed, 2007-01-17 at 13:11 +, 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
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
On 17/01/07, Rafael Schloming <[EMAIL PROTECTED]> 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
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
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
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
On Wed, 2007-01-17 at 13:11 +, 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
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
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
On Wed, 2007-01-17 at 12:25 +, 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
On Wed, 2007-01-17 at 12:25 +, 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
