qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: C++ and Java Broker common configuration and tooling
Date Wed, 06 Jan 2010 19:58:30 GMT
Alan Conway wrote:
> On 01/06/2010 06:52 AM, Robert Godfrey wrote:
>> 2010/1/6 Rafael Schloming<rafaels@redhat.com>
>>> 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:

<feature name="foo" title="Foo">
     Blah blah blah.

   <component name="java-broker"/>
   <component name="cpp-broker"/>

   <test ref="pointer-to-test"/>

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.


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message