On Thu, May 7, 2009 at 8:31 AM, Gordon Sim <g...@redhat.com> wrote:
> Rafael Schloming wrote:
>>
>> Gordon Sim wrote:
>>>
>>> Rajith Attapattu wrote:
>>>>
>>>> Gordon,
>>>>
>>>> Thanks for you feedback. Comments inline.
>>>>
>>>> On Tue, May 5, 2009 at 2:06 PM, Gordon Sim <g...@redhat.com> wrote:
>>>>>>
>>>>>> Suggestions and criticisms are equally welcomed.
>>>>>
>>>>> I am very much in favour of some changes in the configuration of
>>>>> destinations and expanding the capabilities in this regard. However I
>>>>> wonder
>>>>> if perhaps a simpler syntax is possible?
>>>>>
>>>>> Even the simplest example:
>>>>>
>>>>> xqueue.myQueue = name='myQueue'
>>>>> xdestination.myQueue = queue=myQueue
>>>>
>>>> Could you compare with new proposal I sent to the list and see if the
>>>> simplest format is good enough?
>>>> In the new one it would be as simple as
>>>> destinationx.<jndi-name> = myQueue
>>>
>>> So are the following entirely independent and equivalent forms for the
>>> same thing?
>>>
>>> queuex.my-jndi-name = {name=MyQueue, durable=true}
>>> destinationx.my-jndi-queue = MyQueue; {durable=true}
>>>
>>> If so, whats the motivation for the first form?
>>
>> I think the queuex stuff is only to control whether and how you
>> auto-declare queues, so the common case would be:
>>
>> destinationx.my-jndi-name = MyQueue
>>
>> And then if you wanted to auto-declare the queue you would add this:
>>
>> queuex.MyQueue = {auto-create=true, durable=true, ...}
>
> I see. That is not at all obvious (at least to me) from either the syntax or
> the proposal text.
>
> Is the auto-create not implied in that case? I.e. why else would you have a
> queuex type declaration other than to auto-create the queue?
As first step I will move the queuex definition into a separate
section to show that it is different from the destination stuff.
And then we can try to address some of the questions you have raised below.
> Would such a queue be auto-created for either the first consumer or the
> first producer to be created?
>
>> As I understand it you would only add options to the destination in order
>> to configure the individual producers and consumers created from the
>> destination, e.g.:
>>
>> destinationx.my-jndi-name = MyQueue; {prefetch=100, sync=true, ...}
>>
>>> The advantage as I viewed it was more related to intuitiveness (since the
>>> file is a properties file).
>>>
>>>> I think most destination definitions will be quite simple and may not
>>>> be as confusing with the more compact format.
>>>
>>> I don't think the compact syntax is confusing; I think its just another
>>> syntax embedded in the properties file syntax. I could certainly live with
>>> that, but it's probably worth thinking about it and being sure that the
>>> reasons for it are clear.
>>>
>>> I think the source of confusion may be around the various options, what
>>> they mean, how they are interpreted or whether they are valid in a given
>>> context or not.
>>
>> I think the main reason for using this format rather than a flat
>> properties file format is that we also need a syntax for something people
>> can pass to Session.createTopic("...") and Session.createQueue("..."), and
>> the properties file format doesn't work so well for that.
>
> Thats a fair point (at least to an extent!).
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
