qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Command sequences in qpid-config, qpid-route
Date Thu, 09 Dec 2010 14:27:41 GMT
On 12/08/2010 06:37 PM, Jonathan Robie wrote:
> I was talking with Ted about qpid-config and qpid-route, and we
> thought it might be useful to have a simple, consistent syntax using
> one set of conventions for both utilities.
>
> Some other developers suggested that using optparse for all the Python
> command line utilities might lead to more consistency. That helps with
> most utilities, but not with qpid-config and qpid-route, which each
> have a syntax based on sequences of strings.
>
> In this discussion, it became clear that different people are thinking
> of different use cases, and it's not completely clear what the real
> requirements are or which solution would be best.
>
> Here are some requirements that have been mentioned:
>
> - We need a consistent syntax.
>
> - A consistent API that corresponds to the commands these tools offer
> would be helpful. All of the commands in qpid-config and qpid-route
> are also useful within programs
>
> - Machine-readable logging is important for some applications.
>
> - It's important to be able to run these commands in batch mode. Start
> up time is significant, so running a sequence of Python command-line
> utilities in a batch file is slow.
>
> One solution: improve start-up time.
>
> Another solution: design a Python API for these tasks, and use a
> Python script, with one connection, rather than a batch file.
>
> Another solution: allow a sequence of qpid-config or qpid-route
> commands to be placed in a file and executed in batch mode.
>
> - Running commands interactively, in a command shell, and using the
> same commands in a batch file. That makes it easier to write / debug
> scripts.
>
> What other requirements / use cases should we keep in mind?
>
> What other questions should we be asking?
>
> The functionality we need to support is illustrated by the commands
> below my signature. We might choose to support this syntax in some
> form, or perhaps support an API that corresponds to these commands, or
> perhaps support both, with a direct mapping between the two. Are there
> other approaches we should consider?

git and svn follow a common model: a single executable (or python script) that 
offers a set of command, with the general syntax:
qpid-foo cmd [options] <parameters>....

That matches quite nicely with qpid-tool style "qpid-tool show object 139". You 
could allow for a simple "shell"  mode like qpid-tool does now where the 
commands work without the qpid-tool prefix. Then you could roll the 
functionality of other random tools in as extra commands with a common syntax 
and set of base options for all.

>
> Jonathan
>
> ###
> #
> # Parsed representation: verb, noun, parameters (in a map)
> #
> ###
> show object 139
> show object tross
> show queue
> show queue tross
> show exchange
> show exchange xml
> show binding
> show binding exchange=xml
> show binding exchange="xml"
> show binding exchange=xml queue=pqueue
> show binding exchange="xml" queue="pqueue"
> show binding exchange=xml queue=139
> show connection
> # logging
> set log on file="~/tmp/mylog.log" # default is ./qpid.log
> set log off
> # add queue <name> [AddQueueOptions]
> declare queue tross
> declare queue tross durable
> declare queue tross durable=true
> # declare exchange <name> <type> [AddExchangeOptions]
> declare exchange foo # should there be a default type? or is this an error?
> declare exchange a topic
> declare exchange b direct
> declare exchange c fanout
> declare exchange d headers
> declare exchange x xml
> declare exchange bar topic durable=true
> # del exchange <name>
> del exchange bar
> delete exchange bar
> # del queue <name> [DelQueueOptions]
> delete queue xml
> del queue xml
> del queue xml force=True
> del queue xml force=False
> del queue xml force=if-not-empty
> del queue xml force=if-not-used
> # bind
> declare binding exchange queue binding-key
> declare binding xml xqueue binding-key xquery="./weather"
> declare binding xml xqueue binding-key xquery-file=weather.xq
> declare binding header queue any k1=v1 k2=v2
> # unbind <exchange-name> <queue-name> [binding-key]
> del binding topic tross
> del binding exchange queue binding-key
> del binding xml xqueue binding-key
> del binding header queue
>
> declare route from broker=src-broker queue=public to broker=dest-broker
> exchange=fanout
> del route from broker=src-broker queue=public to broker=dest-broker exchange=fanout
> show route from broker=src-broker queue=public to broker=dest-broker
> exchange=fanout
> show route from broker=dest-broker
> show route from broker=dest-broker queue=public
> show route to broker=dest-broker exchange=fanout
>
> declare route from broker=localhost:10001 exchange=amq.topic key=global.# to
> broker=localhost:10002
> declare route from broker=localhost:10001 exchange=amq.topic key=global.# to
> broker=localhost:10002 exchange=amq.topic # exchanges must match
>
> del route from broker=localhost:10001 exchange=amq.topic key=global.# to
> broker=localhost:10002
> del route from broker=localhost:10001 exchange=amq.topic key=global.# to
> broker=localhost:10002 exchange=amq.topic # exchanges must match
>
> del route from broker=localhost:10001 # .eqv. to flush
>
> declare dynamic route from broker=localhost:10001 exchange=amq.topic to
> broker=localhost:10002
>
> map route localhost:10001
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message