Agree. Where we need to start is a design proposal - since we would like it standardised.
We should also check out the iMatix OpenAMQ approach, since it works, and is platform neutral (no matter how much RG disliked it :-) Going to code first on this is likely a huge mistake. John On 25/01/07, Marnie McCormack <[EMAIL PROTECTED]> wrote:
Aargh, I did (of course) mean 'other implementer of AMQP'. Marnie On 1/25/07, Marnie McCormack <[EMAIL PROTECTED]> wrote: > > Absolutely - I agree. > > But let's get the other implementer of Qpid involved since we're > considering a solution which takes into account compatibility with Erlang as > well as our implementing languages. > > We should surely try to opt for the simplest universal fit :-) > > I'd imagine that they have a vested interest here. > > Marnie > > > On 1/25/07, John O'Hara <[EMAIL PROTECTED]> wrote: > > > > 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 > > > > >> > >> > > > > > >> > >> > > > > >> > >> > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > >
