[rabbitmq-discuss] PHP Rabbit Extension

Tony Garnock-Jones tonyg at lshift.net
Wed Mar 31 04:08:45 BST 2010


Hi Pieter,

I must have miscommunicated, sorry about that. The new parameter is
required if you're using *either* the 0-8 or the 0-9-1 branches of
librabbitmq. It's a recent API change that has affected both branches.
I'm not sure what to do about people who can't update to the newest rev
in mercurial, but generally I recommend that people track mercurial
fairly closely.

Perhaps you could recommend using a fixed tag of rabbitmq-c, like
"librabbitmq-0.1-amqp_0_8" or "librabbitmq-0.1-amqp_0_9_1"? You could
recommend getting tarballs using links like this:

http://hg.rabbitmq.com/rabbitmq-c/archive/librabbitmq-0.1-amqp_0_8.tar.gz

? Then, as the API evolves, you can gradually update your recommendation.

Regards,
  Tony

Pieter de Zwart wrote:
> Hey Michael,
> 
> To be honest, Im poking in the dark. I have had repeated emails/tickets
> about people having to add the connection parameter to our
> amqp_get_rpc_reply call. Based on some limited research and chatting
> with Tony, it seemed to me that requiring that function parameter meant
> that they were using the 0-9-1 rabbitmq-c client header file, and
> therefore we running the 0-9-1 client.
> Does that answer your question, or did I miss the point?
> 
> Pieter
> 
> 
> On 3/30/10 8:34 AM, "Michael Bridgen" <mikeb at lshift.net> wrote:
> 
>     Hi Pieter,
> 
>     I cannot give a response on the C client -- I leave that to Tony --
>     however I may be able to offer advice otherwise, since I worked on 0-9-1
>     support in RabbitMQ.  When you say "people tell us [..] they were
>     running 0-9-1" do you mean they are running RabbitMQ on the amqp_0_9_1
>     branch?
> 
>     Regards,
>     Michael
> 
>     Pieter de Zwart wrote:
>     > Alright, I am going to plead my case one more time. We have had a few
>     > people tell us that, since they were running 0-9-1, they needed to
>     tweak
>     > our plugin for it to compile, always having to add that blasted
>     > connection parameter to amqp_get_rpc_reply. Is there ANY WAY you might
>     > consider adding compiler flags, like VERSION “0-9-1” or something so
>     > that we can handle the different signatures transparently (unless you
>     > know of another way, or course)? I want to provide the best possible
>     > experiences to my users, particularly in these early days, and compiler
>     > errors don’t sit well with me. If the signatures for a version change,
>     > so be it, it will be up to us to keep up with it.
>     >
>     > Thank you,
>     > Pieter
>     >
>     >
>     > On 3/22/10 4:50 PM, "Tony Garnock-Jones" <tonyg at lshift.net> wrote:
>     >
>     >     Pieter de Zwart wrote:
>     >     >  The only time we call amqp_get_rpc_reply right now is for
>     our call to
>     >     >  amqp_channel_open after successfully creating a new
>     connection. This
>     >     >  function returns amqp_channel_open_ok_t_, instead of the
>     standard
>     >     >  amqp_rpc_reply_t, so this is the correct place to use it, right?
>     >
>     >     That's right.
>     >
>     >     >  Also, any chance you want to throw in a version string in the
>     >     AMQP.h so
>     >     >  that we can have compiler level flags to handle these different
>     >     >  situations? =)
>     >
>     >     Hmm. I sympathise, but I think it's too early for that: the
>     API, while
>     >     reasonably stable seeming, is I think still best considered
>     officially
>     >     unstable.
>     >
>     >     (You're aware there are a couple of tags in the hg repository
>     now that
>     >     you might be able to use, right?)
>     >
>     >     Regards,
>     >       Tony
>     >
>     >
>     >
>     > --
>     > the rubicon project
>     >
>     > PIETER DE ZWART | INTERFACES ENGINEER
>     >
>     > ••• P 310 207 0272 | x224
>     > ••• F 323 466 7119
>     >
>     >
>     > 1925 S. BUNDY  DRIVE
>     > LOS ANGELES, CALIFORNIA 90025
>     >
>     > WWW.RUBICONPROJECT.COM <_http://www.rubiconproject.com/_>
>     >
>     >
>     > “COMPANY OF THE YEAR” ALWAYSON ONMEDIA 2009
>     > #24 ON FAST COMPANY FAST 50 READER FAVORITES
>     > 2008  ALWAYSON 250 GLOBAL WINNER
>     > 2008 ALWAYSON ONMEDIA 100 WINNER
>     > TWIISTUP3  BEST IN SHOW
>     > PRICEWATERHOUSECOOPERS – ENTRETECH  BEST STARTUP
>     > AMERICAN BUSINESS AWARDS - STEVIES  ‘08 FINALIST BEST NEW COMPANY
>     > AMERICAN BUSINESS  AWARDS - STEVIES ‘08 FINALIST MOST INNOVATIVE
>     COMPANY
>     > AMERICAN BUSINESS  AWARDS - STEVIES ‘08 FINALIST NEW PRODUCT OR SERVICE
>     > -  SERVICES
>     >
>     > P          Please consider the environment before printing this e-mail
> 
> 
> -- 
> the rubicon project
> 
> PIETER DE ZWART | INTERFACES ENGINEER
> 
> ••• P 310 207 0272 | x224
> ••• F 323 466 7119
> 
> 
> 1925 S. BUNDY  DRIVE
> LOS ANGELES, CALIFORNIA 90025
> 
> WWW.RUBICONPROJECT.COM <_http://www.rubiconproject.com/_>
> 
> 
> “COMPANY OF THE YEAR” ALWAYSON ONMEDIA 2009
> #24 ON FAST COMPANY FAST 50 READER FAVORITES
> 2008  ALWAYSON 250 GLOBAL WINNER
> 2008 ALWAYSON ONMEDIA 100 WINNER
> TWIISTUP3  BEST IN SHOW
> PRICEWATERHOUSECOOPERS – ENTRETECH  BEST STARTUP
> AMERICAN BUSINESS AWARDS - STEVIES  ‘08 FINALIST BEST NEW COMPANY
> AMERICAN BUSINESS  AWARDS - STEVIES ‘08 FINALIST MOST INNOVATIVE COMPANY
> AMERICAN BUSINESS  AWARDS - STEVIES ‘08 FINALIST NEW PRODUCT OR SERVICE
> -  SERVICES
> 
> P          Please consider the environment before printing this e-mail




More information about the rabbitmq-discuss mailing list