Ultimately, any command messages which get processed in the server; whether binary marshalled, textual, xml'like, JMX, SNMP, whatever - that needs to be implementable in any technology.
SqlPlus I'd imagine is like isql. The client just blasts text to the server and interprets/displays the results coming back. John On 25/01/07, Marnie McCormack <[EMAIL PROTECTED]> 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. 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 > >> > >> > > >> > >> > >> > >> > >> > > > >> > > >> > > >
