On 24 March 2011 16:19, Rafael Schloming <[email protected]> wrote:

> On 03/24/2011 11:07 AM, Robert Godfrey wrote:
>
>> On 24 March 2011 15:56, Rafael Schloming<[email protected]>  wrote:
>>
>
>
*snip*


>  On 03/24/2011 10:43 AM, Robert Godfrey wrote: rest of qpid...
>>>
>>
>>
*snip*


> Branch is probably the wrong name here... but I'm thinking that this
>> doesn't
>> really fit under the same umbrella as the rest of the components which
>> have
>> a single release cycle currently.  What we possibly want is something that
>> is in parallel to the existing codebase... repos/asf/qpid/trunk/transport
>> in
>> parallel to repos/asf/qpid/trunk/qpid would be one way of doing it...
>> Although looking at other Apache projects it seems like the common way of
>> doing this is
>>
>> .../asf/<project>/<component>/trunk or even
>> .../asf/<project>/<component>/<sub-component>/trunk (see ant, commons,
>> httpd, etc.)
>>
>> Though this would obviously require a little more re-organisation for us
>> all...
>>
>
> I agree we want something parallel. I'm not particularly bothered which
> way, I probably have a mild preference for the <project>/<component>/trunk,
> but if such a reorg would prove to be a pain for some reason I wouldn't be
> particularly bothered by the other way.
>
>
Yeah - that would be my preference too - and also in line with the other
Apache projects.

Given the sort of deadlines we're looking at - ApacheCon, and also the AMQP
1-0 published timelines - I think we need to make a start on this as soon as
possible.  Perhaps after 0.10 is release we could look at putting the svn
change (bringing us in line with other Apache projects) to a vote?

I think getting the UML diagrams in place would be tremendously helpful for
me (at least) to get a slightly better field for where you think the
boundaries between the component parts of the transport layer lie.  The
sooner we have a place for all this in our repo, the better.

At some point I want to step back a bit too, and think how we might support
existing AMQP protocols.  Certainly from the Java side we have endeavoured
to try to support *all* versions of AMQP and translate between them.  In
line with my vision of Qpid as being the de facto reference implementation I
do think we should strive to maintain this aspect of supporting historical
versions somehow too...  It needn't be using the same transport layer, but
it would be much neater if we could :-)

-- Rob


>
> --Rafael
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:[email protected]
>
>

Reply via email to