<div dir="ltr">Ben,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This would of great value. As indicated in my previous mail, we should<br>
promote the client, so this refactoring work should go into the core<br>
build and release process. Because of the centrality of this work, we<br>
may need to consider effects that it would have on the core process.<br>
The various parts of Rabbit have already been broken out into separate<br>
hg repos, which for practical purposes, need to be checked to sibling<br>
directories in order for the build to work (e.g. rabbitmq-server<br>
expects rabbitmq-codegen to be checked out into the same parent<br>
directory). This approach could be taken for a common Erlang module.<br>
</blockquote><div><br>That's good - so it's not an alien procedure.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
The other consideration that you might make is how this patch gets<br>
played back to the Rabbit dev team. You could generate a simple patch<br>
or you could use hg as a DVCS. One consideration with the latter is<br>
that we use named branches for each new feature or bug. If you were<br>
just to clone and implement this in the default branch of your repo,<br>
we may need to think about how to handle the history (because hg<br>
doesn't rewrite it in the same way that git does).<br>
</blockquote><div><br>I don't have any HG experience - it seems like there's now an explosion of configuration management and source code control tools and I just can't keep up :)<br>I will defer to your wisdom in these matters.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
But having said that I don't want to let any formalities get in the<br>
way of you contributing to Rabbit, so at the end of the day, I would<br>
do what is most convenient for you.<br>
<div class="Ih2E3d"></div></blockquote><div><br>Maybe we can meet halfway. I didn't really want to get into rearchitecting the RabbitMQ module structure (well, I wish I could, but I don't have time. The mortgage payment beckons and all that incidental stuff).<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Apart from rabbit_amqqueue and rabbitmq_misc, all of those modules<br>
were designed to be eventually sharable, so that is fine.<br>
<br>
My gut feeling is that rabbit_amqqueue and rabbitmq_misc are purely<br>
server side concerns and if there is a dependency there, we should<br>
look at it and potentially factor it out.<br>
</blockquote><div><br>I agree. I said something like that in one of my other emails before I replied to this one. One could put the factored-out code into the "common" app.<br> <br>Regards,<br>Edwin<br></div></div>
<br></div>