Re: C++ and Java Broker common configuration and tooling
Robert Godfrey wrote: I don't wish to overcomplicate, but do you want some grouping of features... (e.g. a parentFeature tag) if we're looking at the same sort of granularity as unit tests, that should be quite fine... but many of them may be aspects of the same "feature"... Quite possibly. I suspect the format requirements will become more apparent as more content is added. Maybe the first step is to identify all the existing feature-list-type content we have and then see how amenable it all is to being massaged into a single format. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: C++ and Java Broker common configuration and tooling
I don't wish to overcomplicate, but do you want some grouping of features... (e.g. a parentFeature tag) if we're looking at the same sort of granularity as unit tests, that should be quite fine... but many of them may be aspects of the same "feature"... -- Rob 2010/1/6 Rafael Schloming > Alan Conway wrote: > >> On 01/06/2010 06:52 AM, Robert Godfrey wrote: >> >>> 2010/1/6 Rafael Schloming >>> >>> Robert Godfrey wrote: Overall I think with a bit of work from both the C++ and Java > communities > we > can get the brokers to look and behave much more similarly... however > we > will also need to change the way we work a bit so that when we decide > to > add > new features we attempt to discuss and agree before implementing. It > will > do > no good to get the brokers temporarily aligned if they immediately > begin > to > drift apart again. > > I'm just thinking aloud here, but perhaps it would help to gather our various disparate documentation snippits into a single canonical feature glossary somewhere in SVN. Ideally in some format that could be easily fed into the documentation, but could also serve as a source for other things such as generating test matrices, and doing feature based coverage analysis. --Rafael That sounds like an excellent idea... >>> >>> >> Can jrobie's proposed docbook for documentation project provide the right >> format for this? It's XML so should be possible to generate various types of >> file. Seems like something we want to be able to inject into the user doc as >> well. >> > > Possibly, I'm not a docbook expert. Either way I suspect a simple XML file > could be trivially transformed into docbook and whatever else we need, e.g. > something along the lines of: > > > >Blah blah blah. > > > > > > > ... > > > I'm not sure the extent to which we want to cross reference > tests/components/etc against this sort of thing. If that's something we feel > would be valuable then I suspect making up a simple XML format and > translating to docbook would be the way to go. If on the other hand it's > essentially just a documentation-only feature glossary then I'm sure docbook > alone would be sufficient. > > As long as the format is fairly regular, I'm not particularly fussed either > way as it should be straightforward to translate later if necessary. > > --Rafael > > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > >
Re: C++ and Java Broker common configuration and tooling
Alan Conway wrote: On 01/06/2010 06:52 AM, Robert Godfrey wrote: 2010/1/6 Rafael Schloming Robert Godfrey wrote: Overall I think with a bit of work from both the C++ and Java communities we can get the brokers to look and behave much more similarly... however we will also need to change the way we work a bit so that when we decide to add new features we attempt to discuss and agree before implementing. It will do no good to get the brokers temporarily aligned if they immediately begin to drift apart again. I'm just thinking aloud here, but perhaps it would help to gather our various disparate documentation snippits into a single canonical feature glossary somewhere in SVN. Ideally in some format that could be easily fed into the documentation, but could also serve as a source for other things such as generating test matrices, and doing feature based coverage analysis. --Rafael That sounds like an excellent idea... Can jrobie's proposed docbook for documentation project provide the right format for this? It's XML so should be possible to generate various types of file. Seems like something we want to be able to inject into the user doc as well. Possibly, I'm not a docbook expert. Either way I suspect a simple XML file could be trivially transformed into docbook and whatever else we need, e.g. something along the lines of: Blah blah blah. ... I'm not sure the extent to which we want to cross reference tests/components/etc against this sort of thing. If that's something we feel would be valuable then I suspect making up a simple XML format and translating to docbook would be the way to go. If on the other hand it's essentially just a documentation-only feature glossary then I'm sure docbook alone would be sufficient. As long as the format is fairly regular, I'm not particularly fussed either way as it should be straightforward to translate later if necessary. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: C++ and Java Broker common configuration and tooling
On 01/06/2010 06:52 AM, Robert Godfrey wrote: 2010/1/6 Rafael Schloming Robert Godfrey wrote: Overall I think with a bit of work from both the C++ and Java communities we can get the brokers to look and behave much more similarly... however we will also need to change the way we work a bit so that when we decide to add new features we attempt to discuss and agree before implementing. It will do no good to get the brokers temporarily aligned if they immediately begin to drift apart again. I'm just thinking aloud here, but perhaps it would help to gather our various disparate documentation snippits into a single canonical feature glossary somewhere in SVN. Ideally in some format that could be easily fed into the documentation, but could also serve as a source for other things such as generating test matrices, and doing feature based coverage analysis. --Rafael That sounds like an excellent idea... Can jrobie's proposed docbook for documentation project provide the right format for this? It's XML so should be possible to generate various types of file. Seems like something we want to be able to inject into the user doc as well. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: C++ and Java Broker common configuration and tooling
2010/1/6 Rafael Schloming > Robert Godfrey wrote: > >> Overall I think with a bit of work from both the C++ and Java communities >> we >> can get the brokers to look and behave much more similarly... however we >> will also need to change the way we work a bit so that when we decide to >> add >> new features we attempt to discuss and agree before implementing. It will >> do >> no good to get the brokers temporarily aligned if they immediately begin >> to >> drift apart again. >> > > I'm just thinking aloud here, but perhaps it would help to gather our > various disparate documentation snippits into a single canonical feature > glossary somewhere in SVN. Ideally in some format that could be easily fed > into the documentation, but could also serve as a source for other things > such as generating test matrices, and doing feature based coverage analysis. > > --Rafael > > > That sounds like an excellent idea... -- Rob > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > >
Re: C++ and Java Broker common configuration and tooling
Robert Godfrey wrote: Overall I think with a bit of work from both the C++ and Java communities we can get the brokers to look and behave much more similarly... however we will also need to change the way we work a bit so that when we decide to add new features we attempt to discuss and agree before implementing. It will do no good to get the brokers temporarily aligned if they immediately begin to drift apart again. I'm just thinking aloud here, but perhaps it would help to gather our various disparate documentation snippits into a single canonical feature glossary somewhere in SVN. Ideally in some format that could be easily fed into the documentation, but could also serve as a source for other things such as generating test matrices, and doing feature based coverage analysis. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: C++ and Java Broker common configuration and tooling
On 01/04/2010 04:27 PM, Robert Godfrey wrote: Happy New Year all... So, at the start of this new year I think it is important that we try to focus on improving the experience of our project... and in particular I think we should be looking at making the project look like a single coherent whole. I agree, that is a valuable goal. Currently the Java and C++ Brokers look and behave almost completely differently, and I think we all should be trying hard to remedy that situation. The first step in my grand plan to fix this was obviously implementing AMQP 0-10 The next task I set myself was to investigate how we can use a single set of management and configuration tools across the two brokers such that the user experience is common. To that end I have spent the last couple of weeks implementing a prototype QMF management layer in the Java Broker, attempting to use the same management schema as used by the C++ broker. Further I have implemented the required methods to enable federation between Java and C++ (and to use the same tools to set it up) - both static and dynamic routing has been implemented. Excellent, thanks for your hard work! (I feel suitably embarrassed having spent the last two weeks eating and sleeping!) Once trunk is unfrozen I will be able to apply my patch that provides for qpid-tool, qpid-route et. al to work against the Java Broker. In implementing QMF Management and Federation I have come up against a number of obstacles caused by assumptions built in to the QMF management schema that are based on the behaviour of the C++ broker (e.g. that it doesn't support multiple vhosts), I also have a number of questions/comments on the schema as a whole. I've collected all these on the following wiki page: http://cwiki.apache.org/confluence/display/qpid/Broker+Management+QMF+Coverage I would be grateful if those familiar with the C++ broker and it's management could answer some of the questions therein... Further I would like to get feedback on my comments and suggestions for additions to the management capabilities. From those more familiar with the Java management capabilities - a review to point out any other capabilities that cannot be carried out through QMF would be very helpful. In terms of next steps in uniting the user experience: 1) I think we need to collectively agree on how we can update the management schema to work fully with the Java Broker and hopefully to expand its coverage to that it encompasses everything that can currently be performed by the Java JMX management solution. 2) I will be trying to put together a wiki page of all the "extensions" to AMQP that the brokers currently implement (e.g. arguments to queue/exchange declare, bind,subscribe, etc...). ultimately we should try to unify these as well - and also to define a mechanism so that clients can detect on connection which extensions are available. Beyond the configuration and management work I've started already, the biggest gap is probably ACLs - and I've not looked at all at that yet. Overall I think with a bit of work from both the C++ and Java communities we can get the brokers to look and behave much more similarly... however we will also need to change the way we work a bit so that when we decide to add new features we attempt to discuss and agree before implementing. It will do no good to get the brokers temporarily aligned if they immediately begin to drift apart again. Your thoughts? Thanks for taking the lead on this! I think this would greatly benefit to the Qpid community. (I have filled in some detail on the c++ extensions and added a few comments/answers on the management coverage page to begin with). --Gordon. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org