qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chenta lee <che...@gmail.com>
Subject Re: [jira] Updated: (QPID-1766) Implemention of selector using Xquery
Date Mon, 23 Mar 2009 06:12:22 GMT
I already add an option to let user decide whether parse the content or
not.
setting.arguments.setInt("qpid.selector_parse_content", 1);

set qpid.selector_parse_content to 1 will enable broker to parse the message
content, vice versa.

Chenta

On Mon, Mar 23, 2009 at 10:10 AM, Carl Trieloff <cctrieloff@redhat.com>wrote:

> Robert Greig wrote:
>
>> 2009/3/22 chenta lee <chenta@gmail.com>:
>>
>>
>>
>>> Yes, what I mean is the concept of message selector, not how we implement
>>> it. And Xquery is mush more powerful than SQL-92 syntax.By MQ, I refer to
>>> Message Queue instead of a particular message queue project.
>>>
>>>
>>
>> OK. xquery may be semantically richer but the JMS message selector
>> functionality operates on message headers not message bodies.
>> Selecting on headers will be hugely faster than on the body. There are
>> clear use cases for both.
>>
>>
>>
>
>
> I know Jonathan has updated the XML exchange to not parse the body if the
> Query only specifies
> headers. We should do that here too.
>
>
>  I am a little confused about how could my patches related to patent issue?
>>>
>>>
>>
>> I am not sure of the details of exactly what Red Hat has patented (I
>> have not read the patent text myself). However the Red Hat people are
>> on this mailing list so I am sure they will be able to clarify. From
>> what I have read, the patent covers an AMQP exchange that implements
>> xquery which is not what you are describing.
>>
>>
>>
>
> no, it isn't related at all. The piece that it covered has already been
> provided under a license grant to
> the ASF (XML Exchange), and will be feely licensed to anyone that uses AMQP
> if it is ever granted.
>
> regards,
> Carl.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message