Clean-rooming

[Michael Bridgen]

Hi all,

I would like to suggest that libraries developed here proceed only
from the specification; specifically, without reference to existing
code (Rob's, Rafael's, or other implementations developed here if
there's more than one).

The rationale is this: the specification is intended to provide for an
interoperable protocol. Independently developing client libraries
that can interoperate strengthens the specification as well as the
implementations.


Michael

[Rafael Schloming]

I agree we should be very careful about spreading assumptions between implementations. That said one of my goals for this group is also to share some of the work, so I wouldn't want to see all 20 of us go off into separate corners and build out separate implementations. ;)

I think one thing we can do here is be fairly diligent about keeping track of any questions on interpretation during any implementation efforts, e.g. if something is unclear post to the list. I know it can be all to easy to just make a choice in the heat of coding and move on and then forget about it later.

Another way I think we can share is by taking advantage of the layering, e.g. I've kept my codec independent from the rest of my code, so if you don't care about the codec, then I think it's fairly safe to borrow that part without much danger of contamination.

--Rafael

[Robert Godfrey]

On 24 June 2010 00:55, Rafael Schloming <r...@alum.mit.edu> wrote:
> I agree we should be very careful about spreading assumptions between
> implementations. That said one of my goals for this group is also to share
> some of the work, so I wouldn't want to see all 20 of us go off into
> separate corners and build out separate implementations. ;)
>
> I think one thing we can do here is be fairly diligent about keeping track
> of any questions on interpretation during any implementation efforts, e.g.
> if something is unclear post to the list. I know it can be all to easy to
> just make a choice in the heat of coding and move on and then forget about
> it later.

Agreed... I also agree with Michael's point that new code should be developed
from the specification, not from looking at existing code. This was also how
I developed the Java (although obviously Rafi and I have a lot of shared
state). Obviously testing against the existing code and then discussing where
there are issues interoperating will be of great benefit in potentially finding
issues in the spec.

If we find specification ambiguities we should try to raise them on the
amqp.org dev list if possible, as well as here - we should also maintain
some sort of implementation FAQ over there.

I'm keen to get my Java code out where people can see it... but in order to
do that, this project needs a name... so that I can get my contract amended
to add to the list of "named" open source projects I may contribute to. Any
suggestions?

-- Rob

[Hiram Chirino]

How about this:

http://github.com/amqp/amqp-java-client

What's your github account name?

On Fri, Jun 25, 2010 at 7:00 AM, Robert Godfrey <rob.j....@gmail.com> wrote:

I'm keen to get my Java code out where people can see it... but in order to

do that, this project needs a name... so that I can get my contract amended
to add to the list of "named" open source projects I may contribute to.  Any
suggestions?

-- Rob

--
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://fusesource.com/

[Robert Godfrey]

On 25 June 2010 13:44, Hiram Chirino <hi...@hiramchirino.com> wrote:
> How about this:
> http://github.com/amqp/amqp-java-client
> What's your github account name?

That should work... I'm rgodfrey at github

thanks,
Rob

[Hiram Chirino]

Ok, you should be able to push to that repo now.