I reached out to them today; I think they would like to be more involved. Something to discuss on Wednesday.
Note: The RabbitMQ chaps have signed the RLA so can participate. John On 25/01/07, Steve Vinoski <[EMAIL PROTECTED]> wrote:
On Jan 25, 2007, at 4:47 AM, Marnie McCormack wrote: > I guess if we need to be supporting Erlang we should get the AMQP > WG to > involve the RabbitMQ team in the discussion ? They'd be best placed to > discuss how it could be done from their perspective. +1. If the AMQP WG specifies a portable management "language" while avoiding forcing any particular requirements for underlying implementation choices, which is exactly how the WG needs to operate, then I don't believe that implementing it in Erlang would be a problem. Still, bringing the RabbitMQ guys into the community certainly can't hurt. --steve > > Marnie > > > On 1/25/07, Rafael Schloming <[EMAIL PROTECTED]> wrote: >> >> I hadn't pictured using python as a server embedded language, just >> as a >> good way to write really low maintenance command line utilities >> (including a sqlplus like one) that can easily talk to many different >> broker implementations. >> >> Of course now that you mention it python is probably one of the >> easiest >> languages to embed in both Java and C++ (don't know about Erlang), >> and >> it is a much more full featured language than many other candidates >> (e.g. javascript, groovy, etc, have some frustrating limitations when >> writing larger pieces of code). >> >> --Rafael >> >> John O'Hara wrote: >> > Over at AMQP WG we want to standardise basic management to make it >> portable >> > -- think DDL / DML. >> > >> > So the server implementation of the commands needs to be able to >> process >> > some command language **within** the server. >> > The command processor will need to be emeddable into both Java >> and C/C++ >> > (and Erlang - see RabbitMQ). >> > This likely means some custom scheme (think DDL / DML). >> > >> > Given this objective, which is important to end users, embedding >> Python >> > into >> > the brokers may not be the most sensible option (it may be a >> sensible >> thing >> > for the command line client, but the command processor in the >> server >> needs >> > to be more agnostic). >> > >> > This is somewhere that designing it first will pay off before >> running to >> > the >> > ID(L)E :-) >> > >> > Cheers >> > John >> > >> > On 24/01/07, Jesus M. Rodriguez <[EMAIL PROTECTED]> wrote: >> >> >> >> +1 for python >> >> >> >> On 1/24/07, Rafael Schloming <[EMAIL PROTECTED]> wrote: >> >> > +1 >> >> > >> >> > I'm probably biased, but IMHO python would be an ideal choice >> for >> this. >> >> > >> >> > John O'Hara wrote: >> >> > > We also need to do a command line client for AMQP. >> >> > > Its very necessary.... >> >> > > >> >> > > John >> >> > > >> >> > > On 12/01/07, Bhupendra Bhardwaj <[EMAIL PROTECTED]> >> wrote: >> >> > >> >> >> > >> Hi Nuno, >> >> > >> >> >> > >> patch applied. >> >> > >> >> >> > >> Regards, >> >> > >> Bhupendra >> >> > >> >> >> > >> >> >> > >> On 1/12/07, Nuno Santos <[EMAIL PROTECTED]> wrote: >> >> > >> > >> >> > >> > Bhupendra Bhardwaj wrote: >> >> > >> > > So I have applied the other part of the patch and created >> >> different >> >> > >> > scripts >> >> > >> > > for gtk and motif. We can similarly create scripts for >> other >> >> > >> windowing >> >> > >> > > system too without changing the config.ini. >> >> > >> > > I think it is better from a user point of view to have >> different >> >> > >> script >> >> > >> > for >> >> > >> > > different windowing system instead of changing the >> config. >> >> > >> > >> >> > >> > Bhupendra, >> >> > >> > >> >> > >> > thanks for applying the patch... and I agree with you >> regarding >> >> having >> >> > >> > the additional scripts vs. having to tweak a config file. >> >> > >> > >> >> > >> > Btw, I uploaded a 2nd patch to include your new scripts >> in the >> >> tar/zip >> >> > >> > files: >> >> > >> > >> >> > >> > >> >> > >> >> >> >> https://issues.apache.org/jira/secure/attachment/12348845/ >> management-eclipse-plugin-unix.xml-20070112.patch >> >> >> >> > >> >> >> > >> > >> >> > >> > Nuno >> >> > >> > >> >> > >> >> >> > >> >> >> > > >> >> > >> >> >> > >>
