On Thu, Sep 20, 2012 at 4:00 AM, Rob Godfrey <rob.j.godf...@gmail.com> wrote: > On 20 September 2012 00:32, Rajith Attapattu <rajit...@gmail.com> wrote: > >> Hi All, >> >> There are a few folks who are keen to have AMQP 1.0 support for our JMS >> client. >> Given that the parent AMQP TC is starting a bindings and mappings TC >> which will cover JMS, I thought it would be a good idea to get a >> discussion going on here as well. >> We could aim to build the client as we progress through the TC and >> provide feedback if necessary. >> >> On the hand, we've had extensive discussions on building a new JMS >> client from scratch when adding 1.0 support. >> The primary motivation was to address some of the nagging issues >> around the old client. >> >> So far there have been two schools of thought on how to get AMQP 1.0 >> support. >> >> 1. JMS Client --> Qpid API --> Proton >> >> 2. JMS Client --> Proton >> >> While option #1 seems like killing two birds with one stone, I think >> we should seriously consider option #2 as well. >> >> > So, regardless of which path we take I think we need to carefully define > the functional requirements for our JMS client. Looking at the JIRAs, and > based on the experience of supporting the current client, the two areas > where it causes most problems are 1) failover and 2) addressing. > > For both (but especially failover) I think we need a very clear > understanding of the functionality we are looking for the client to provide > before we can decide which layer it is best placed in. If the functionality > is likely to be common across the JMS and Qpid APIs then it would seem > sensible not to write this code directly into the JMS layer. > > Before we start cutting any code I think we need general agreement in the > Qpid Java community about the functionality that is required and where it > is going to be implemented (and ideally we should also be coordinating by > whom it is going to be implemented also :-) ).
Indeed! My intention was to get this conversation happening and for us to start formulating a plan. As I mentioned in my original email, a plan is very important, so we know who's doing what and more importantly some milestones as to when we can expect things to happen. I agree with you about the main problem areas. I also think we need to pay very close attention to our threading and synchronization strategies as we have quite a few issues there. We should put up a page on wiki to document the requirements and have a conversation happening on the lists to come to an agreement. We should then define milestones and deliverables. Without that it's going to be meaningless. Once we do that we could start coordinating about the code contributions and adjust the plan if we feel we have resourcing issues. Rajith > -- Rob > > > >> I would love to hear everybody's thoughts on this. >> More importantly it's good if we could also discuss on a plan and set >> some milestones to ensure we stay focused. >> >> Personally I would love to see a reasonably working prototype by 0.22. >> If we can get something going for 0.20 that would be a bonus, even if >> it's just experimental (preferably on a branch) and Alpha quality. >> >> I mentioned the above milestones to kick start the discussion and get >> things rolling. >> We could start on a branch and then move it to trunk during 0.22 if >> everybody is satisfied with the progress. >> >> Regards, >> >> Rajith >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >> For additional commands, e-mail: dev-h...@qpid.apache.org >> >>